Re: Problem missing FindBugs

[Victor Williams Stafusa da Silva]

FindBugs is pretty much dead BTW. It doesn't work with Java >= 9 (and
barely with Java 8) nor is actively mantained anymore.

However, SpotBugs is the FindBugs sucessor. SpotBugs is a fork of FindBugs
and they value backwards compatibility. So, the migration should be easy.

This way, any docs, plugins or code referring to FindBugs should be updated
to refer to SpotBugs instead.

Victor Williams Stafusa da Silva

Em sex, 1 de mar de 2019 às 11:19, Jeremy Cavanagh <
jeremy.cavan...@orange.fr> escreveu:

> Hi Geertjan,
>
> I've just done a fairly comprehensive pass through the document,
> modifying a few things and checking for FindBugs dependency. Of eight
> major sections only three do not require FindBugs.
>
> Although these sections discuss configurations (customizing, creation &
> deletion), I don't think it's worth continuing at present.
>
> Regards
>
> Jeremy
>
> On 2019/03/01 12:33:45, Geertjan Wielenga 
> wrote: > On the other hand, FindBugs is only part of that document --
> I'd recommend> > commenting out all parts that deal with FindBugs for
> the moment and leaving> > the rest in there.> > > Gj> > > On Fri, Mar 1,
> 2019 at 12:56 PM Geertjan Wielenga <> >
> geertjan.wiele...@googlemail.com> wrote:> > > > Yes, let’s hide that
> tutorial from the trail until we figure this out.> > >> > > Gj> > >> > >
> On Fri, 1 Mar 2019 at 12:19, Jeremy Cavanagh > > >
> wrote:> > >> > >> Hi,> > >>> > >> I have just started working on
> code-inspect.asciidoc. I expressed some> > >> concerns in an earlier
> message. However, I am now trying to follow the> > >> instructions and
> hit a problem, "FindBUgs Integration" is not currently> > >> available
> in the NetBeans plugin portal. This makes the whole of this> > >>
> tutorial impossible to complete.> > >>> > >> Any thoughts?> > >>> > >>
> Regards> > >>> > >> Jeremy> > >>> > >>
> -> >
>  >> To unsubscribe, e-mail:
> dev-unsubscr...@netbeans.incubator.apache.org> > >> For additional
> commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: What Coding Conventions Should We Follow Now? What should the IDE default to?

[Victor Williams Stafusa da Silva]

Whatever is the convention adopted, I only implore one thing: Do not allow
tabs be the default setting!

By the way, a better integration with checkstyle would be welcome.

Victor Williams Stafusa da Silva

2018-04-26 11:32 GMT-03:00 Wade Chandler <wadechand...@apache.org>:

>
> > On Mar 16, 2018, at 6:46 AM, Emilian Bold <emilian.b...@protonmail.ch>
> wrote:
> >
> >> Rather than discussing the actual conventions, make sure the IDE can
> read and apply settings from Eclipse easily and exactly.
> >
> > Not sure what this means. Just make sure plugins are able to format the
> code?
> >
> > Still, NetBeans does provide formatting and coding hints. Both should
> follow /something/ and I assume Wade was wondering what standard to follow.
> >
>
> Exactly, and too, what makes the most sense.
>
> > My angle is that NetBeans, just like Eclipse, *is* a de-facto standard.
>
> I don’t necessarily agree this makes the most sense, but I understand your
> point. I guess for me this comes up as a source of friction when working on
> projects. Intellij is by far the most used with Eclipse next, and then us.
> I think either choosing some agnostic, and well written standard, or using
> a real de-facto, sort of like how Spring became one over JEE, being used
> more, makes for less friction.
>
> Perhaps the answer is to provide NBs historical one as it is our code
> base, and use that one with our project (NetBeans itself). Then provide
> some others which are largely popular such as IntelliJ, Eclipse, Google,
> and “Old Sun Java” for users of the IDE to use out of the box. It doesn’t
> seem likely teams are going to go, oh, yeah, the few NB IDE users
> formatting options win out over everybody else, and too, other projects are
> not likely to provide a format which is easy to just import without some
> upfront setup on behalf of the NB users. Too, most places in my experience
> don’t come up with their own formatting. They generally pick one which
> exists and is published. Us providing common ones makes that even easier
> for IDE users.
>
> Thanks for the replies and feedback all. I think I’ll look at this area
> soon to see what can be done.
>
> Wade
>
>
> ===
>
> Wade Chandler
> e: cons...@wadechandler.com
> t: @wadechandler
> https://www.linkedin.com/in/wade-chandler
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Netbeans encoding

[Victor Williams Stafusa da Silva]

I'm working right now on a legacy web project that uses a bunch of
System.out.println for logging and debugging. It was plagued by a lot of
encoding problems, and I fixed most of them by forcing everything to be
UTF-8. There is no sense in using the platform default encoding when the
text output is something to be embedded into HTML and juggling/converting
strings of different encodings around is what I considers a form of
torture. Also, reading text/config/html/java/whatever files written in
different encodings and having to guess what is the correct encoding on a
case-by-case basis just makes it a still worse torture.

Also, I done the translation of Checkstyle to Portuguese and the
translation files are encoded in UTF-8. When using them in my project,
Checkstyle prints localized messages of code-style violations, and those
became garbled in the netbeans console. Don't know if this is a Checkstyle
bug, but even if it is, having to do encoding checks and conversions just
to println a String for debugging purposes is a burden that no programmer
should deserve to have. Also, even if it is a Checkstyle bug and someone
gets to fix it, there would be probably more millions of tools out there
with the same bug.

Ok, Netbeans can't do anything to fix a bunch of tools that have encoding
problems. However this show that the hole here is much bigger: the simple
existence of the concept of a default platform encoding is the root cause
of all those problems. Even a simple System.out.println statement may
suffer from this problem because you don't know and can't know (and ideally
shouldn't need to know or care) if the String it is going to the console,
to a file, to a socket or to anywhere else. It only works safely when all
the produced strings born, live and die within the same machine, an
assumption that is and always was simply plain false and wrong. This is why
I strong support the idea of deprecating any methods that rely on the
default platform encoding. Netbeans could also do its part by not ever
relying on that.

Victor Williams Stafusa da Silva

2018-04-21 3:53 GMT-03:00 Tim Boudreau <niftin...@gmail.com>:

> No argument that the situation doesn't need a fix.
>
> But you didn't answer my question:  *What* are you running when the problem
> shows up?  Your own Java project?  If so, Ant, Maven or something else
> (i.e. build system where this is settable/detectable or not?)?  Or some
> application server or third party thing?
>
> What I'm trying to nail down is, what is the point of minimal intervention
> where this could either be detected or made settable.  External processes
> in Java have binary output;  the IDE decides what character set to impose
> over that.  That decision can be improved, but not without knowing what the
> stream is coming from there's no place to start.  Without knowing what it
> is you're looking at the output of when you see this problem, there's no
> progress to be made.
>
> I'm all for UTF-8 everywhere in theory, and on my own systems, but
> defaulting to that is likely to break things for at least as many people as
> it helps.  So, in the interest of solving it with a scalpel instead of a
> sledgehammer, could you give a little detail on where the problematic
> output is coming from and how it is generated?
>
> Thanks,
>
> -Tim
>
> On Fri, Apr 20, 2018 at 8:33 PM, Victor Williams Stafusa da Silva <
> victorwssi...@gmail.com> wrote:
>
> > In my case, I'm running in windows, with the dreaded and hated
> Windows-1252
> > default encoding.
> >
> > Using default OS encoding is really bad for portability and causes a lot
> of
> > encoding problems. See this JEP draft maybe for Java 11:
> > http://openjdk.java.net/jeps/8187041 - There are three proposed
> > alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
> > uses the platform default encoding; 3) Force UTF-8 deing the default
> > regardless of anything.
> >
> > As a speaker of Portuguese, a language that is full of diacritics, I'm
> > already very sick of years and years of being haunted by encoding
> problems
> > in buggy software. But it could be much worse if my language was Chinese
> or
> > Japanese.
> >
> > Since option 1 is unacceptable and 3 is too drastic and dangerous due to
> > backwards-compatibility concerns, I think that this JEP, if it eventually
> > gets delivered, will go to option 2.
> >
> > Anyway, regardless of this JEP or its future, Netbeans should either get
> > the correct encoding in the console window or at least provide an easy
> and
> > accessible way to et the user define it.
> >
> > Victor Williams Stafusa da Silva
> >
> >
> > 2018-04-20 20:00 GMT-03:00 Tim Boudreau <niftin...@gmail.com>:
> >
> 

Re: Netbeans encoding

[Victor Williams Stafusa da Silva]

In my case, I'm running in windows, with the dreaded and hated Windows-1252
default encoding.

Using default OS encoding is really bad for portability and causes a lot of
encoding problems. See this JEP draft maybe for Java 11:
http://openjdk.java.net/jeps/8187041 - There are three proposed
alternatives: 1) Keep the status quo; 2) Deprecate all the methods that
uses the platform default encoding; 3) Force UTF-8 deing the default
regardless of anything.

As a speaker of Portuguese, a language that is full of diacritics, I'm
already very sick of years and years of being haunted by encoding problems
in buggy software. But it could be much worse if my language was Chinese or
Japanese.

Since option 1 is unacceptable and 3 is too drastic and dangerous due to
backwards-compatibility concerns, I think that this JEP, if it eventually
gets delivered, will go to option 2.

Anyway, regardless of this JEP or its future, Netbeans should either get
the correct encoding in the console window or at least provide an easy and
accessible way to et the user define it.

Victor Williams Stafusa da Silva


2018-04-20 20:00 GMT-03:00 Tim Boudreau <niftin...@gmail.com>:

> Your problem is most likely your operating system's default file encoding
> here (perhaps MacRoman?).  The IDE is assuming that process output is
> whatever your operating system's default encoding is, which is the right
> assumption, since that *is* what command-line utilities will output.  It
> happens that the process you're running is outputting UTF-8 *rather than*
> the
> OS's default encoding.
>
> Setting that as a default would be assuming that every operating system
> uses UTF-8 regardless of what it does - it would be wrong a lot of the
> time.  It just happens to solve the case that whatever you're running is
> outputting UTF-8 in spite of what the operating system provides.
>
> That's not that uncommon, but the right solution is to *detect* that the
> output is UTF-8 when the IDE runs whatever it is you're running.
>
> So... what are you running?  Is this project output?  If so, what kind of
> project?  Or server output of some kind?  A correct fix would be to (if
> possible), detect what that is and that it will output UTF-8, and have the
> IDE open the output of that process with the right encoding.
>
> -Tim
>
> On Fri, Apr 20, 2018 at 6:18 PM, Victor Williams Stafusa da Silva <
> victorwssi...@gmail.com> wrote:
>
> > I frequently had some long-standing problems with the console output
> > encoding in Netbeans. Which always presented garbled non-ascii characters
> > for me.
> >
> > After deciding that it was enough, I went to search for a solution and
> did
> > found a very simple one in StackOverflow. Just add
> -J-Dfile.encoding=UTF-8
> > into the netbeans_default_options line of netbeans.conf file and voilà,
> it
> > works!
> >
> > However, this make me think about it:
> >
> > 1. Is there a reason to not add it there by default?
> >
> > 2. If it can't be added there by default for some reason, can it at least
> > be something more user-friendly and less arcane to be configured by the
> > normal user?
> >
> > Victor Williams Stafusa da Silva
> >
>
>
>
> --
> http://timboudreau.com
>

Netbeans encoding

[Victor Williams Stafusa da Silva]

I frequently had some long-standing problems with the console output
encoding in Netbeans. Which always presented garbled non-ascii characters
for me.

After deciding that it was enough, I went to search for a solution and did
found a very simple one in StackOverflow. Just add -J-Dfile.encoding=UTF-8
into the netbeans_default_options line of netbeans.conf file and voilà, it
works!

However, this make me think about it:

1. Is there a reason to not add it there by default?

2. If it can't be added there by default for some reason, can it at least
be something more user-friendly and less arcane to be configured by the
normal user?

Victor Williams Stafusa da Silva

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

I was waiting for an answer from the lombok team before giving further
feedback here.

I created this issue there:
https://github.com/rzwitserloot/lombok/issues/1617 and this pull request:
https://github.com/rzwitserloot/lombok/pull/1626

For me, this simple one-line fix solved the issue on lombok's side.

At netbeans side, maybe testing if the retrieved URI before calling toURL()
is a good idea.

Victor Williams Stafusa da Silva

2018-03-13 4:59 GMT-03:00 Jan Lahoda <lah...@gmail.com>:

> Hi Victor,
>
> Thanks for looking at this. Some comments inline.
>
> On Tue, Mar 13, 2018 at 12:02 AM, Victor Williams Stafusa da Silva <
> victorwssi...@gmail.com> wrote:
>
> > Anyway, independent of how much lombok finger-pointing, blaming or
> flaming
> > we have, there seems to be something indeed problematic in Netbeans side.
> > If I use Maven or Gradle to build a non-modular lombok project in Java 9,
> > it builds correctly afterall, but Netbeans chokes with that.
> >
> > Looking at the source, the problems comes from line 113 of
> > PatchModuleFileManager, which is this:
> >
> > final URL url = fo.toUri().toURL();
> >
> > This is the link:
> >
> > https://github.com/apache/incubator-netbeans/blob/
> > master/java.source.base/src/org/netbeans/modules/java/source/parsing/
> > PatchModuleFileManager.java#L113
> >
> > That "fo" is a javax.tools.JavaFileObject instance probably provided by
> > lombok or by something else related. The toUri() method provides a
> > java.net.URI object which is then converted to a java.net.URL. However,
> the
> > toURL() method throws an exception for URIs that aren't absolute.
> >
> > Although I can go on to the lombok source trying to understand how and
> why
> > the heck the non-absolute URI is generated and also talk with them about
> > the issue, I first want to know if JavaFileObject instances should be
> > allowed to have non-absolute URIs, since the toUri() method javadocs are
> > silent about that.
> >
> > The Netbeans code clearly and strongly assumes that whichever instance of
> > JavaFileObject received will always provide an URI which can be derived
> to
> > a URL (and so, the URI has to be absolute). The URL is compared with many
> >
>
> I believe the code in NetBeans expects that it will get JFOs which NetBeans
> has constructed. Which apparently is not the case here. This is not a
> completely wrong assumption: I am not aware about any API that would allow
> to inject external JFOs into javac. I guess a solution here might be to
> ignore unknown JFOs, which is what the standard file manager in javac is
> doing, for better or worse.
>
> URL keys of a Map to see if it is a child of some of those accordingly to
> > the toExternalForm() method (which produces a String). The keys to the
> Map
> > are produced by the parseModulePatches(Iterator) method
> > of the org.netbeans.modules.java.source.parsing.FileObjects class.
> >
> > My first tought is that the URI indeed must be absolute in order to
> clearly
> > be able to refer to a unambiguously identifiable resource.
> >
> > But on a second thought, it might (or might not) make sense that
> > code-generating tools provides URIs that aren't absolute.
> >
> > On a third tought, even if non-absolute URIs make no sense, Netbeans
> could
> > try to provide some defense against that (i.e: if the URI is a "file://"
> or
> > "jar://", but is not absolute, normalize it before proceeding). This
> would
> > not only serve the purpose of defending from questionable practices on
> > lombok side, but on any other weird code-generation-on-the-fly tool that
> > will come around in the next corner tomorrow. Since there is no clear and
> > explicit requirement that the toURI() method shoudl provide an absolute
> > URI, trying something to remedy the situation if that occurs might be a
> > good idea.
> >
> > On a forth thought, as I said in this list in a moment last year (looking
> > for that very same issue, but had not enough time to chase it deeper),
> > using URLs instead of URIs seems to be dangerous because the equals
> method
> > of the URL class sucks, making it a poor choice as a key to a map.
> However
> > (as someone also said at that time), we are still in the safe side
> because
> > the URL's equals method delegates the work to the StreamHandler which
> have
> > no problems when the protocol is "file://" and "jar://", which are the
> ones
> > produced from java.util.File by the inner guts of the parseModulePatches
> > met

Re: Netbeans cache and configurations

[Victor Williams Stafusa da Silva]

I created to issues in JIRA about this thread:
https://issues.apache.org/jira/browse/NETBEANS-514 and
https://issues.apache.org/jira/browse/NETBEANS-516

Victor Williams Stafusa da Silva

2018-03-21 19:54 GMT-03:00 Derik Devecchio <ddevecc...@celestron.com>:

> My first message was not fully baked and my intended meaning was missed.
>
> I was trying to point out that after 1-2 years of use, my Netbeans 8.1
> cache was still a reasonable size, ~140 MB.   From my one data point, I
> don’t see that there is a cache problem at all.  Only a Maven Index problem
> which is a different beast.  Are other people’s “large cache” problems also
> tied to use of maven central’s 2.5GB index?   There may be some people that
> consider even 140 MB of cache data to be a problem.
>
> Thanks Emilian for pointing me to the “on line” plugin for maven to avoid
> using the local index.   My alternative was to copy the one maven-central
> library that I still use to our local repository, but this plugin idea
> seems much more elegant way to manage this.
>
> As for the size of the maven index, Gili asked about the downsides of
> using the plugin by default.   Maybe the default should be to not use an
> indexer at all.   Projects that are available in a maven repository
> frequently publish the POM entry in a copy/paste format right in the
> “downloads” section.   I have never had to rely on autocompletion in a POM
> file to get my work done.   My maven usage may be atypical.
>
> —
> derik
>
>
>
> On Mar 21, 2018, at 12:08 AM, Emilian Bold <emilian.b...@protonmail.ch<
> mailto:emilian.b...@protonmail.ch>> wrote:
>
> I have used NetBeans 8.1 on my Mac of at least a year, maybe 2.   Upon
> investigation 2.49 GB of the 2.63 GB that were in my cache were located in
> maven indexes/central/.I have only use one library in Maven Central
> (others are in a local repository).   I was unaware that adding that small
> project (less than 10 classes) was causing maven to chew up almost 2.5 GB
> of HDD space.
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__plugins.
> netbeans.org_plugin_68415_maven-2Dremote-2Dsearch=DwIFaQ=
> euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM=
> LEbKaWj9ZrFRBadYtwZVnHfoaHpGoEmzs1DrtRBDEg8=
> A2yEU57VLfbAoySIU9qsy4iuseO1wDRLy_Jhtk7H9co=L-iWe6-z67YTGw5kiEZTWTKZxH-
> wZUGtEZhQAL4HdNI= , made by me, which I believe should become the
> default in NetBeans installs (after much testing, rewriting, etc.)
>
> ​--emi
>
> I have used NetBeans 8.1 on my Mac of at least a year, maybe 2.   Upon
> investigation 2.49 GB of the 2.63 GB that were in my cache were located in
> maven indexes/central/.I have only use one library in Maven Central
> (others are in a local repository).   I was unaware that adding that small
> project (less than 10 classes) was causing maven to chew up almost 2.5 GB
> of HDD space.
>

Re: Netbeans cache and configurations

[Victor Williams Stafusa da Silva]

 @cowwoc

I was debugging and hacking lombok, and so making Netbeans crazy. I won't
go through the details in this thread to not hijack it and I will answer
something in the other one soon. However (lombok aside) it is rare for me
to get Netbeans confused about something, it was much more common some
years ago.

Also, I understand about the security stuff, but I guess that this should
be optional. If Alice and Bob cooperatively programs in the same computer
both with their own users, then if Alice installs a (say) Jenkins plugin,
Bob shouldn't be required to download it once again. Also, if Alice
compiles that maven project with millions of dependencies that downloads
the internet, it would be a pain if later, Bob have to do it all over
again. So, maybe there could be a setting somewhere to say (a: "I use
Netbeans exclusively within my user account"; b: "I want to share my
Netbeans with other users accounts of this computer").

@Antonio

I'm somewhat a newbie here and don't know yet how to file a JIRA issue, but
will find out how to do that. It seems that we have two issues here: the
cache-purge issue and the user-sharing issue, so I would file two. Wouldn't
it be marked as a dup to @Валера's bug on bugzilla?

Also, I downloaded the old plugin and gave a look at it and it is not what
I expected because: (1) It asks the user to tell the path where the
Netbeans cache is instead of finding it out that by itself; (2) It do not
knows or care if the user are really telling the truth and will delete all
the files in the given path, even if it has nothing to do with the Netbeans
cache; (3) It takes no measures whatsoever to protect NetBeans from
shooting itself in the foot or something like that other than just asking
the user to save everything and warning that it could cause abnormal IDE
termination; (4) It also relies on an (optional) external file unlocker
program that should be provided by the user to ensure forcefully deletion
of files.

Victor Williams Stafusa da Silva

2018-03-20 18:28 GMT-03:00 Валера Солдатов <v.f.solda...@gmail.com>:

> Also we had https://netbeans.org/bugzilla/show_bug.cgi?id=267606
>
> 20.03.2018 23:33, Antonio пишет:
>
> Some comments below
>>
>> On 20/03/18 19:01, Victor Williams Stafusa da Silva wrote:
>>
>>> [big complaint removed for the sake of space]
>>>
>>
>> Please file an issue in JIRA and label it as an enhancement.
>>
>>
>>> So, I'll question if there is a easy way to purge the cache from the
>>> inside
>>> of the IDE that I'd overlloked so far for whichever reason? If not, would
>>> it be a good idea to add that? Also, is there a way to rate-limit it to
>>> avoid it consuming too much disk space?
>>>
>>
>> It's probably not easy to purge the cache while running. We could devise
>> a way to delete/clean it up when the IDE exits, or when it starts.
>>
>>
>>> I am very far from knowning the gory details of NetBeans internal stuff,
>>> so
>>> I am afraid that I am just talking bullshit here and this is a big
>>> misunderstanding, sorry if this is the case. However, even if this is the
>>> case, I would likely to know nonetheless.
>>>
>>
>> This is not bullshit. It's a nice feature, IMHO.
>>
>> Some other IDEs have this feature as well. XCode, for instance, is able
>> to delete some internal directories it uses, and that get in the way _all_
>> the time.
>>
>> I'd like to have a feature where you could see how much cache you're
>> using and to remove it somehow. Also a list of previous NetBeans version
>> directories could be provided, with proper delete buttons also.
>>
>>
>>> It is not just me that hit this issue. Google for "netbeans cache" and
>>> most
>>> of the results will be from people asking about how to clear the cache
>>> because NetBeans got confused or something like that. There is even an
>>> old
>>> plugin called "Cache Eraser".
>>>
>>
>> Ah, so we had a plugin for that.
>>
>>
>>> Victor Williams Stafusa da Silva
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.incubator.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.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Netbeans cache and configurations

[Victor Williams Stafusa da Silva]

A long-time personal complaint I had against Netbeans was about its caches
and configurations. In modern Windows, it is located on
C:\User\\AppData\Local\NetBeans and
C:\User\\AppData\Roaming\NetBeans folder. For Linux or McOS, it
is something similar. It is sometimes a pain in the ass for me due to
several reasons:

1. The cache is overbloated. It gets only larger and larger over
days/months/years of usage. After some months or years of intense NetBeans
usage, if nothing/nobody intervenes, it will easily reach some gigabytes
full of mostly useless old data.

2. They lies hidden deeply in the filesystem far from the eyes of mere
mortals (in a hidden folder!). So, few median NetBeans users even know
about its existence or have any idea about how to interact with that.

3. If that gets corrupted for some strange reason, there is no way to clear
it inside the IDE AFAIK. I must go to the deep guts of the filesystem and
delete it. Otherwise, with a corrupted cache, Netbeans gets confused (rare
for me today, but was common for me in the NetBeans 6.x and 7.x days).

4. It lies in user-specific space. So, if my computer is used by several
different users, they'll likely get duplicate caches (even for the same
projects located in the same HD physical locations), duplicate plugins,
duplicate maven repositories, etc. This means a lot of wasted disk space
with duplicate stuff.

5. The cache will easily accumulate hundreds of thousands of small files or
perhaps even a few millions over the years. Those will tend to be very
scattered at the disk, which might lead to poor disk performance when you
make a backup by simply copy+pasting the Users folders to some other drive
or when you just delete those damn Netbeans folders. Also, I strongly
suspect that this contributes to disk fragmentation and they waste a lot of
space by leaving a lot of disk blocks consumed but mostly empty.

So, I'll question if there is a easy way to purge the cache from the inside
of the IDE that I'd overlloked so far for whichever reason? If not, would
it be a good idea to add that? Also, is there a way to rate-limit it to
avoid it consuming too much disk space?

I am very far from knowning the gory details of NetBeans internal stuff, so
I am afraid that I am just talking bullshit here and this is a big
misunderstanding, sorry if this is the case. However, even if this is the
case, I would likely to know nonetheless.

It is not just me that hit this issue. Google for "netbeans cache" and most
of the results will be from people asking about how to clear the cache
because NetBeans got confused or something like that. There is even an old
plugin called "Cache Eraser".

Victor Williams Stafusa da Silva

Re: Usability study was: Think Java, not Electron! was: Apache HTML/Java UI

[Victor Williams Stafusa da Silva]

I did not read all the e-mails in this long thread, and I'm probably
somewhat late to answer. But since people are/were talking about electron
(or other replacements for Swing/AWT/JavaFX), let's give a look at this and
not commit the same mistakes:
https://josephg.com/blog/electron-is-flash-for-the-desktop/

2018-03-18 17:15 GMT-03:00 Kirk Pepperdine :

>
> > On Mar 18, 2018, at 2:57 PM, Neil C Smith  wrote:
> >
> > Hi Kirk,
> >
> > On Sun, 18 Mar 2018 at 08:12 Kirk Pepperdine  wrote:
> >
> >> There are entire classes of applications that cannot be easily managed
> in
> >> HTML today. HTML/JS simply doesn’t scale in it’s current incantation.
> >> Without Swing/FX there are no good alternatives in Java.
> >>
> >
> > This reminds me of a conversation we were having last summer.
>
> Indeed, it’s a conversation that continues...
> >  With
> > respect, I think there's still some misunderstanding of the proposed
> > approach.
>
> I use HTML in Java UI’s and it works very well when used appropriately.
> For other cases, including the management of large data sets, Swing/FX
> offer better solutions at least for now. A large part of the problem is the
> translation of the data set to HTML as sometimes it’s difficult to know
> what is immediately needed.
>
> — Kirk
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

Anyway, independent of how much lombok finger-pointing, blaming or flaming
we have, there seems to be something indeed problematic in Netbeans side.
If I use Maven or Gradle to build a non-modular lombok project in Java 9,
it builds correctly afterall, but Netbeans chokes with that.

Looking at the source, the problems comes from line 113 of
PatchModuleFileManager, which is this:

final URL url = fo.toUri().toURL();

This is the link:

https://github.com/apache/incubator-netbeans/blob/master/java.source.base/src/org/netbeans/modules/java/source/parsing/PatchModuleFileManager.java#L113

That "fo" is a javax.tools.JavaFileObject instance probably provided by
lombok or by something else related. The toUri() method provides a
java.net.URI object which is then converted to a java.net.URL. However, the
toURL() method throws an exception for URIs that aren't absolute.

Although I can go on to the lombok source trying to understand how and why
the heck the non-absolute URI is generated and also talk with them about
the issue, I first want to know if JavaFileObject instances should be
allowed to have non-absolute URIs, since the toUri() method javadocs are
silent about that.

The Netbeans code clearly and strongly assumes that whichever instance of
JavaFileObject received will always provide an URI which can be derived to
a URL (and so, the URI has to be absolute). The URL is compared with many
URL keys of a Map to see if it is a child of some of those accordingly to
the toExternalForm() method (which produces a String). The keys to the Map
are produced by the parseModulePatches(Iterator) method
of the org.netbeans.modules.java.source.parsing.FileObjects class.

My first tought is that the URI indeed must be absolute in order to clearly
be able to refer to a unambiguously identifiable resource.

But on a second thought, it might (or might not) make sense that
code-generating tools provides URIs that aren't absolute.

On a third tought, even if non-absolute URIs make no sense, Netbeans could
try to provide some defense against that (i.e: if the URI is a "file://" or
"jar://", but is not absolute, normalize it before proceeding). This would
not only serve the purpose of defending from questionable practices on
lombok side, but on any other weird code-generation-on-the-fly tool that
will come around in the next corner tomorrow. Since there is no clear and
explicit requirement that the toURI() method shoudl provide an absolute
URI, trying something to remedy the situation if that occurs might be a
good idea.

On a forth thought, as I said in this list in a moment last year (looking
for that very same issue, but had not enough time to chase it deeper),
using URLs instead of URIs seems to be dangerous because the equals method
of the URL class sucks, making it a poor choice as a key to a map. However
(as someone also said at that time), we are still in the safe side because
the URL's equals method delegates the work to the StreamHandler which have
no problems when the protocol is "file://" and "jar://", which are the ones
produced from java.util.File by the inner guts of the parseModulePatches method
(if we ever change that by producing an "http://; URL somewhere, we would
be screwed, so I consider this approach fragile and questionable at least).
But, thinking about the code, I see a loop bruteforcing a bunch of URLs
trying to match the JavaFileObject with any of them, for every
JavaFileObject that eventually comes along. This doesn't seems to be an
efficient approach for this problem on the Netbeans side.

Anyway, this code at least explains why we have no problem in JDK 8. It is
part of the code which handle modules which do not exist prior to Java 9.

My conclusion is that the bug is probably lombok's fault, since it
generates a JavaFileObject without an absolute URI. But on lombok's
defense, there is nothing in the specification of javax.tools.FileObject
saying that the URI must be absolute. Also, regardless of this fact,
perhaps Netbeans could fix the issue on its side as well.

Victor Williams Stafusa da Silva

2018-03-10 16:06 GMT-03:00 Gili T. <cow...@bbs.darktech.org>:

> Josh,
>
> Try JDK 9 specifically.
>
> The fact that they use bytecode injection makes their library very
> unstable.
>
> Gili
>
> On Sat, Mar 10, 2018, 11:59 Josh Juneau <juneau...@gmail.com> wrote:
>
> > I will chime in to mention that I utilize Lombok with NetBeans 8.2 and it
> > works most of the time.  There are some annoyances that I've noticed, but
> > it is most certainly due to the fact that Lombok is a compile-time
> > process...not a library, as mentioned in a previous thread.  Typically
> if I
> > change my Maven POM file at all, I need to clean my project, deleting
> > "target", and recompile twice...a priming compile to download the Lombok
> > dependency and then another to

UnsatisfiedLinkError on exception report

[Victor Williams Stafusa da Silva]

 For me, whenever Netbeans 9.0 beta gets an exception, it is shown up in a
window asking me to submit a bug report. I submitted it and the exception
reporter tab tells me that it was classified as a duplicate. When I click
the link of the dup, I get another exception containing this:

java.lang.UnsatisfiedLinkError: no extbrowser64 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at
org.netbeans.modules.extbrowser.NbDdeBrowserImpl.(NbDdeBrowserImpl.java:82)
at
org.netbeans.modules.extbrowser.SystemDefaultBrowser.createHtmlBrowserImpl(SystemDefaultBrowser.java:94)
at org.netbeans.core.NbURLDisplayer.warmBrowserUp(NbURLDisplayer.java:100)
at org.netbeans.core.NbURLDisplayer.access$000(NbURLDisplayer.java:47)
at org.netbeans.core.NbURLDisplayer$1.run(NbURLDisplayer.java:59)
Caused: org.openide.util.RequestProcessor$SlowItem: task failed due to
at org.openide.util.RequestProcessor.post(RequestProcessor.java:395)
at org.netbeans.core.NbURLDisplayer.showURL(NbURLDisplayer.java:55)
at
org.netbeans.modules.exceptions.ReporterResultTopComponent$4.run(ReporterResultTopComponent.java:380)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
at
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
[catch] at
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)

Well, an UnsatisfiedLinkError seems to be a serious issue about Netbeans
assemblage.

I submitted this problem also. It was classified as a duplicate of #217695
which is not filled in bugzilla yet.

Is it broken only for me or did someone else also hit this problem? BTW,
I'm using Windows 8.1. Does this have something to do about components
which were excluded due to some licensing problem?

Victor Williams Stafusa da Silva

Re: Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

Well, lombok is filled with eclipsy stuff because it is a parasitic
compiling tool, not a library. Keep that in mind, since many people misses
that: LOMBOK IS NOT A LIBRARY. In javac, it does its black magic by
invading javac's inner AST's. For eclipse, it is worse because it replaces
some of eclipse's compiler classes (or something like that, I'm not really
sure about all the gory details).

However, it is somewhat common to see preople adding lombok as a runtime
dependency. By being a build tool, like javadoc/ant/javac, you shouldn't
add it as a runtime dependency. It is a compile-time-only dependency and
should never be added to runtime classpaths, so the produced JAR/classfiles
should not have any dependency with lombok ever. So, by being a tool that
is plugged onto the compiler and never be used at runtime, it would benefit
little from stronger modularization. As I said, it is not a library and
should not be used as such, it is solely a build tool.

But then you have byte-buddy that generates things at runtime and uses
lombok for that. But lombok should not be used at runtime as a library, so
we have a contradiction here. The problem here is that to do it's black
magic, byte-buddy needs to use parts of lombok as a library, but lombok was
not built to be a library afterall.

So, what you are telling me seems to be more-or-less a great
misunderstanding. We could use the case of byte-buddy to persuade lombok
guys to better modularize it by actually seeing some valor in doing so,
since now, lombok (or at least part of it) would be a library afterall and
not just some weird part of the compiler toolchain. However, by opening up
a ticket at their github to say that you have some trouble compiling it and
that "*I have filed a bug with byte-buddy-dep, requesting they stop using
lombok. It is really the worst Java package I have ever come across.*" you
immediatelly thrown away any hope to get some collaboration out of those
guys and also failed to explain them what was the real issue you were
trying to solve.

However, flaming that over here would be unproductive. I can go and submit
a bug report to lombok guys asking for better modularization by providing a
clear reason for that. But, this is no excuse to not attack the problem on
Netbeans side. So, what is wrong with
PatchModuleFileManager.getLocationForModule and
ProxyFileManager.getLocationForModule? The
PatchModuleFileManager.getLocationForModule
method seems to be the one that tries to produce a bad URL. If the problem
is solely lombok's fault afterall (dunno), what types of defenses can
Netbeans use to avoid that some weird tool messing around with compiler's
internal stuff breaks everything?

Victor Williams Stafusa da Silva

2018-03-09 18:54 GMT-03:00 William L. Thomson Jr. <wlt...@o-sinc.com>:

> On Fri, 9 Mar 2018 16:11:23 -0500
> cowwoc <cow...@bbs.darktech.org> wrote:
>
> > I gave up using Lombok with JDK 9 months ago. Yes, it is far more
> > unstable under Netbeans than with other IDEs but it is generally a
> > mess under JDK9 regardless of which IDE you use.
>
> I am not a fan of Lombok either.
>
> I reported a build issue under 9, and their recommendation was to use
> ant to build it...
> https://github.com/rzwitserloot/lombok/issues/1562#issuecomment-363549169
>
> Which I fail to see how that would solve the issue.
>
> src/core/lombok/javac/apt/Javac9BaseFileObjectWrapper.java:38: error:
> Javac9BaseFileObjectWrapper is not abstract and does not override
> abstract method getSibling(String) in PathFileObject
> class Javac9BaseFileObjectWrapper extends
> com.sun.tools.javac.file.PathFileObject {
>
> Compiler errors like that are not resolved by ant/maven/gradle. Unless
> they are doing something I could as well, modifying files, options,
> etc. I run into stuff like that a lot and requires code fixes. I do not
> believe they implemented that class properly in the first place.
> Something is very odd there per my comments and attempts to fix.
> https://github.com/rzwitserloot/lombok/issues/1562
>
> I have filed another issue with byte-buddy to eventually move away from
> Lombok. It requires a massive amount of Eclipse to build from source.
> If your building Netbeans from source. You end up with a lot of Eclipse
> dependencies, just because of Lombok.
> https://github.com/raphw/byte-buddy/issues/397
> https://github.com/apache/incubator-netbeans/blob/master/spi.java.hints/
> nbproject/project.properties#L24
>
> I was able to switch over to Google AutoValue in byte-buddy for
> Netbeans 9 using sed in a crude manner.
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/
> master/dev-java/byte-buddy-dep/byte-buddy-dep-.ebuild#L47
>
> Not sure if that was successful or not. It allows byte-buddy to build,
> and I can build the pieces of Netbeans that need byte-buddy, like
> spi

Netbeans 9.0 is very unstable with lombok in JDK 9

[Victor Williams Stafusa da Silva]

Hi, I download latest Netbeans 9.0 beta last week and I'm using with JDK 9.
My lombok projects makes Netbeans really unusable.

Those are the steps for reproducing it:

1. Create a new project.
2. Set the properties of the project to ensure that it is using JDK 9.
3. Download lombok-1.16.20.jar and put it in the project libs folder,
adding it in the project properties page.
4. Create the following class:

import lombok.NonNull;

public class NetbeansLombokBugTest2 {
public static void main(@NonNull String[] args) {
}
}

5. Save the file (Ctrl+S). Modify it by adding a blank space somewhere and
save it again (Ctrl+S).

Netbeans will start to spam repeatedly the error "IllegalArgumentException:
URI is not absolute". This bug makes Netbeans almost unusable to work with
lombok on JDK 9. Whenever you touch anything in the project, even other
java source files that have nothing to do with lombok, you'll get the
spamming error screen popping up regardless of anything.

The bug seems to not be reproducible if the project uses JDK 8 is used
instead.

I am already getting some occasional other further errors when I insist in
using the IDE regardless of prior errors, however I was still unable to
isolate them so far.

I already reported something similar a few months ago, but I weren't able
to isolate the bug at that time and due to many real-life issues I had not
enough time to research it much further.

Is anyboby able to reproduce it?

Victor Williams Stafusa da Silva

Re: Header on Java source code files

[Victor Williams Stafusa da Silva]

"/**" comments that are not intended to be parsed by the javadoc tool
should be considered as either an anti-pattern or a bug in my opinion.
There is simply no sane reason in doing that. "/**" comments should be used
only for javadocs and nothing more. For things that have nothing to do with
javadocs, the "//" and the standard "/*" comments should be used.

A related, but different, issue is that javadoc syntax in non-javadoc
comments is a problem too. Already saw many people using that in the form
of "/* (non-javadoc) @see blahblah */" comments, but can occasionally be
seen in other forms. This is an anti-pattern in my opinion.

2017-11-18 17:33 GMT-02:00 Lars Bruun-Hansen :

> I've noticed that AL2 license headers for Apache NetBeans in Java source
> code files start with the Javadoc introducer, i.e. "/**" rather than just
> "/*". Even on .c and .h files this is the case.
>
> I've checked how the IDE itself does it on a fresh project where you ask it
> to apply some type of license header: It will - correctly - start with
> "/*", not "/**". I've also looked around how other projects do it, for
> example the JDK itself : all examples I've found use "/*". It was also only
> a "/*" back in Hg days.
>
> By starting the license header with "/**" we are telling the Javadoc parser
> that this is something it should pay attention to. Luckily on a standard
> class source file, Javadoc will ignore such comment because it comes before
> the package declaration. On a package-info file it won't be ignored, unless
> another Javadoc entry follows it.
>
> It may be minor, but I think it should be fixed. Better now than later.
>
> Opinions on this?
>

Lombok (and perhaps other broken annotation processors) makes Netbeans nuts.

[Victor Williams Stafusa da Silva]

I am an user (not a dev) of Lombok, and I'm facing issues with using Lombok
in Netbeans.

Currently, lombok do not works (at least for me) with Netbeans if using
Java 9. It does seem to work when I compile it by using Gradle at the
command line. See this:

https://github.com/rzwitserloot/lombok/issues/1435

Also, if lombok, when doing its back-magic annotation processing is able to
mess up netbeans, so something else would probably also be. Although the
lombok guys will eventually fix this issue on their side and even if it is
unfeasible to handle every case of a broken annotation processor messing
with the IDE for whichever reason, Netbeans should at least try to handle
this issue graciously.

Victor Williams Stafusa da Silva

Re: Reproducible NetBeans builds [WAS: Re: HTML/Java checksums was: Release Apache NetBeans 9.0 Alpha (incubating)]

[Victor Williams Stafusa da Silva]

Not sure if someone already mentioned or acknowledged that, but let's give
a look at this:

http://zlika.github.io/presentations/devoxx_fr_2016/reproducible-builds/slides_en.html

Victor Williams Stafusa da Silva

2017-11-09 16:30 GMT-02:00 Antonio <anto...@vieiro.net>:

> El 09/11/17 a las 13:36, Emilian Bold escribió:
>
>> Every built of a jar will produce a different sha, so you're assessment
>>>> is correct.
>>>>
>>>
>>
> Mmm that would depend on how you checksum the jar file. I imagine that
> we could checksum all the contents of the jar file _except_ for specific
> lines in the META-INF/MANIFEST.MF file (those talking about build times and
> jdk versions). The rest of the file should produce the same checksum (being
> compiled with the same JDK). Let's call this the "Java Checksum", right?.
>
> Computing the "Java Checksum" will, of course, be costly performance-wise,
> I think.
>
> So we could have a secondary, optional, "Java Checksum" for binaries. If
> the first usual SHA-1 checksum (quick to compute) fails then a "Java
> Checksum" would be used instead.
>
> Cheers,
> Antonio
>
> P.S.: Another option would be to prune those lines that get modified in
> each build in the MANIFEST.MF file after creating the jar file.
>
>
> Another reason NetBeans builds should be reproducible.
>>
>> Rather amazed Apache does not have a foundation-wide move like Debian's
>> https://wiki.debian.org/ReproducibleBuilds
>>
>> --emi
>>
>>

Re: Java 18.3 and IntelliJ

[Victor Williams Stafusa da Silva]

I know that my opinion is probably irrelevant to those guys, but I think
that if they want to name the version that way, they should at least use
four digit years. This would:

* Avoid some confusion from people asking "we had Java 9 and now Java 18,
where are 10, 11, 12, 13, 14, 15, 16 and 17?"

* Show that we learned a lession from the nasty Y2K bug. Who knows if Java
would still be around in 2100? Few to no people seriously think that it
will, but many software solutions end living way longer than what it is
antecipated and still getting updates and improvements for quite a long
time.

Victor Williams Stafusa da Silva

2017-11-02 12:56 GMT-02:00 Christian Lenz <christian.l...@gmx.net>:

> As someone said, it would be great that NetBeans could be the first DIE to
> Support Java 18.3, well, to late: https://blog.jetbrains.com/
> idea/2017/11/intellij-idea-2017-3-eap-brings-support-for-
> local-variable-type-inference/?utm_source=feedburner_
> medium=feed_campaign=Feed%3A+jetbrains_intellijidea+%
> 28JetBrains+IntelliJ+IDEA+Blog%29
>
> I mean yeah not to late but there are already News for the next Version of
> Java in the blog of IntelliJ. Only to let you know that fact.
>
>
> Regards
>
> Chris
>
>