We Keep Coding

Cannot run Apache Netbeans 11 using JDK 11

No matter what I do, I can't get Netbeans 11 to work with JDK 11. Can you help me out?
Please note that this issue does NOT occur with JDK 8.
Downloaded and installed JDK 11 to C:\Program Files\Java\jdk-11.0.4
Downloaded and unzipped Netbeans 11 to C:\Program Files\netbeans
The etc/netbeans.conf file has been edited to set JDK home:
netbeans_jdkhome="C:\Program Files\Java\jdk-11.0.4"
When trying to run bin/netbeans64.exe:
First time: The loading window appears, loads for a bit, and then the
whole program disappears.
Second time: Loading window does not appear. An empty Java application
appears.
If I go to Task Manager and manually end the Netbeans process, I can
get back to First time.
For the attachments listed below, please refer to the issue I created here:
https://issues.apache.org/jira/browse/NETBEANS-2865
Executing netbeans64.exe from PowerShell outputs error messages to the console. They can be found in consoleOutput.txt attachment.
The results from executing bin/netbeans64.exe --trace C:\netbeans.log can be found in netbeans.log attachment.
For reference, this is the tutorial I followed:
https://www.youtube.com/watch?v=cxh-hVty09g
Update & Solution
I FINALLY got it to work thanks to the answer provided by skomisa.
The issue was caused by Netbeans 11.0 importing settings from a previous version. There was a popup the first time I ran Netbeans 11.0 asking if I wanted to import my settings from a previous version. Refer to skomisa's answer for more details on why.
To solve it, I deleted ALL of the preference files for NetBeans 11 by deleting the entire folder in AppData.
C:\Users\Hunter\AppData\Roaming\NetBeans\11.0\
Skomisa's answer mentioned trying to create a new unzipped version of NetBeans 11 and not importing the settings. I had actually tried this previously, but never got the popup window asking if you want to import. I assume this is because the user preference files for this version of NetBeans have already been created and are still sitting in AppData.
This leaves you with two viable options:
Delete all of the user preference files for NetBeans 11.0.
Search through the entire folder for instances of \u0000 and remove them.
It seemed easier and more satisfactory to remove the entire folder and start from scratch. That way, all of my user preference files are using the newest practices accepted by the JDK and Netbeans and that, hopefully, there is no lingering legacy code that will randomly break the next time I update.
Thanks for everyone's help!

Your problem appears to be related to the IllegalArgumentException ("Key contains code point U+0000") in the console log output of your bug report. It looks like NetBeans is trying to import your preferences from an earlier release of Netbeans, and is is finding some invalid null character(s) in your preference file(s).
This has been bug reported before, but remains unresolved. See Bug 271652 - IllegalArgumentException: Key contains code point U+0000.
Your preference files are all XML files (with extension xml), and reside in various directories under C:\Users\user ID\AppData\Roaming\NetBeans\11.0\config.
In my case my only preference file for NetBeans 11 is named C:\Users\johndoe\AppData\Roaming\NetBeans\11.0\config\Editors\text\x-java\Preferences\org-netbeans-modules-editor-settings-CustomPreferences.xml but you may have more than one.
From the stack trace in your console log, the failing call is AbstractPreferences.getBoolean(), so the null is probably on a line containing Boolean in your preference file. However, as this somewhat related SO answer suggests, just blindly remove all nulls from all preference files. Nulls should never exist in any XML file anyway.
An alternative approach to solving your problem is to create a new unzipped version of NetBeans 11, but do not import your settings.
I suppose you could even locate the preference files in your existing (broken) NB 11 installation and delete them, though that seems like an unsatisfactory approach even if it works.
A few related points:
Seeing the NetBeans window appear briefly before it vanishes is often a symptom of having set netbeans_jdkhome to an invalid JDK path, but in your case the value looks fine.
JAVA_HOME is ignored by NetBeans, so that cannot be the cause of your problem. See the response to Bug 198950 - NetBeans should use the JAVA_HOME and JDK_HOME environment variables, if available, to determine which JDK to use for details on how NetBeans decides which JDK to use. Specifying the --jdkhome parameter when you start NetBeans will override everything else.
The IllegalArgumentException only arises with JDK versions >= 9 because of a JDK bug fix, but that's a good thing. See JDK-8075156 : (prefs) get*() and remove() should disallow the use of the null control character '\u0000' as key for details. You weren't getting the problem with NetBeans 8.x because you probably weren't ever importing any preference files, but even if you were the IllegalArgumentException would not have occurred due to the Java bug fixed by JDK-8075156.

Eclipse seems to think the CSS files are Java source code

I'm using Eclipse Eclipse IDE for Java Developers [Version: 2018-12 (4.10.0)
Build id: 20181214-0600] to develop a JavaFX project but I got some problems.
After a Java update, I've found several errors in my CSS files. Eclipse seems to think the CSS files are Java source code, as figured in the image below.
When I drag the mouse on a error, the description is "Syntax error on token 'Invalid character', interface expected" (because of # symbol)
I'm sure the code is correct because there are no errors before the latest java update to version 1.8.2.
Anyone can help me?

Most likely what happened here is what #Gianpio Benincasa said: You've created a new class, then in the file explorer you renamed it.
However, it's worth checking this one: Go to window/preferences, type 'associations' in the filter box to quickly nav to setting General>Editors>File Associations, and scroll through the file types list for *.css. Click on it, and check which editors are associated with it.
An eclipse with no particularly relevant plugins should only list 'Text Editor', and it should be marked as default. If you added plugins specifically for editing CSS, those will also be listed (and one of those is now probably default instead). Perhaps you or someone else went out of their way to add the java editor to this list somehow. If that is the case, simply make 'text editor' the default again (click it, click 'default'), then click on the java editor, and click 'remove'.

for eclipse that is a java class, in fact the icon has the "J". Probably when you created it you have created a new class and then have renamed it.
Create a new generic file instead a java class and copy the contents to the new file.
For create a generic file, rightclick and follow new-> other-> General-> files
Have a nice day

attract attributes typing java plugin for rhapsody

I need to write a java plugin will draw on the attributes using the rhapsody . What do you recommend for that. Where should I start ? Previously I did not write plug-ins.

First place to start is to look at the samples provided by IBM. You can find them (on Windows 7, version 7.5.3 of Rhapsody) in:
C:\Users\\IBM\Rational\Rhapsody\7.5.3\Samples\ExtensibilitySamples
There are 3 types you can create:
1. A plugin (what you are asking about)
2. A Check plugin (ties into the model check sub-system)
3. Event callback plugin (don't know much about this one)
I've written 1 and 2.
There should be a how-to document in and around that directory area that walks you through creating a simple plugin. If not, it probably is available in the Rhapsody help (from within the tool)
Basically, you write your Java plugin to conform to a specific interface that IBM provides(com.telelogic.rhapsody.core.RPUserPlugin), create a .hep file that describes the details of that, and then drop the .hep file into the .rpy folder of your project. You then create a new profile in your model with the same name as your .hep file and that should link to the .hep information.
A sample .hep file looks like this:
[Helpers]
numberOfElements=1
#REM: Tranformer Generation plug-in
name1=Generate Transformers
JavaMainClass1=sida.jni.transformerplugin.TransformerPlugin
JavaClassPath1=..\TransformerPlugin\DefaultConfig
isPlugin1=1
isVisible1=1
DLLServerCompatible1=1
Take special note of the numbers added to the end of the attribute names:
ex. isPlugin1, isVisible1
You will want to match that to the name# attribute in the file.
Then make sure your java plugin class files are on the classpath or (better yet), co-located to your .rpy folder. For example, our plugins sit in a folder right next to (at the same level as) our .rpy folder.
If all goes well, you should see an initialization string spit out in the Rhapsody console window for the plugin.
Hope this gets you started...

Watch expression doesnt show value in eclipse with java

I am using eclipse helio with java.
The watch expression option is not working for me when debugging my code
If I am doing a watch on variable, I cant see the value of that variable in the watch view
if i hoover with my mouse over the variable in the code i can see its value
if I check the variable in the variables view I can see its value
but in the watch expressions window i cant see its value (and its a problem if i try to watch expressions for example)
did anyone encounter this problem
(it used to work fine and show values but then suddenly it stopped and i have no idea why)
thanks

For me the problem had to do with a bad source path configuration for the project. There's a bunch of different ways to fix this, but one is to right-click on the thread while paused in the debugger, select "Edit Source Lookup...", and fiddle around with the paths specified there (see below).
In my case the problem was that I had specified the source lookup path as a "File System Directory". I was able to get my Expressions view working again by removing the "File System Directory" path and adding the source lookup as a "Java Project" instead.
You can check whether the problem is your source lookup path by opening the Debug -> Display view, and trying to evaluate a Java expression there. If you see a message like this, then your source lookup path is bad:
To perform an evaluation, an expression must be compiled in the context of a Java project's build path. The current execution context is not associated with a Java project in the workspace.

Typically (at least for simple cases) the expression view works. But sometimes it indeed stops showing the values.
Usually refresh and clean of project + (sometimes) restart of eclipse help.
If you are able to see simple values and cannot see expression it sometimes because the class that is returned by expression does not appear in import list of current class. In this case I often try to write explicit cast to class into the watch expression and sometimes it helps.
Good luck.

In my case, while debugging against wildfly, my workspace somehow got corrupted after I opened as a maven project the sources of eclipselink 2.6.4.
After having open this maven project - that has all sort of dependencies you can image on oracle libraries - within my workspace the expressions and display view simply did not work any more. The variables view, while debugging continue to work as well as all the mouse overs.
I then created a fresh new empty worksapace.
Imported only the project I wanted to debug.
Reconfigured wildfly server.
And voila, expressions and display were back to work.
So, I have no idea what what happened to my eclipse... but it appears to be related to the metadata in my workspace being fundamentally broken.
Therefore, if you get the feeling that out of the blue lose the ability to properly debug in your workspace, it might be that your worksapce got hammered.
This appears to be what has happened to me. Finally, I am now back to being able to use the expressions on this new workspace.

How to track down JAR with corrupt JAR Index that cause InvalidJarIndexException in Tomcat in Eclipse

I am working with development of an application which, among other pieces of code, contains a number of servlets. The development environment I use is Eclipse (3.2.1, which is rather old) in which I run a Tomcat server (5.5.23, rather old as well) using the Eclipse Tomcat Wrapper plug-in for the task. All this runs on a RedHat 5.2 Linux system.
The Java runtime I use is JDK 1.6.0(21), which I upgraded to (from a previous JDK 1.5 version) quite recently and as far as I can recall, the software combination above (together with the application I'm working with) did actually work: I could start the Tomcat server, it got up without errors or complaints and the application's servlets were available on port 8080.
However, something has changed somewhere (could be in the application jarfiles themselves, I'm suspicious of essentially everything on the host to be the root cause of this). Now, when I try to start up the Tomcat server, I get the error sun.misc.InvalidJarIndexException in the console output. This happens for the following classes and methods:
org.apache.commons.modeler.Registry registerComponent (happens 3 times)
org.apache.catalina.core.StandardServer initialize (happens once)
org.apache.catalina.connector.Connector start (happens twice)
I did find this stack overflow question regarding how to find the JAR of a Java Class useful and I did run find /usr -name \*name-of-suspected-jar\*.jar a few times to track down a number of suggested offending JARS. I also tried to check the runtime configuration of the Tomcat server in Eclipse, but could really not match the JAR files on the system with the CLASSPATH of neither the Tomcat runtime setup (or with the CLASSPATH used in the environment when starting Eclipse). That effort probably requires some more rigor on my part but before doing that (and that is why I right now don't post all the gory details regarding CLASSPATHs here), I did a read up on exactly what InvalidJarIndexException really is about.
So, JAR files may contain an optional INDEX.LIST file which contains information about what classes (and methods?) to find in the JAR file. The idea is to short-circuit the search throughout all JARS in the CLASSPATH which is useful in a number of circumstances. Problem is when the INDEX.LIST file happens to be corrupt (or, is believed to be corrupt), that causes the loading of the class to be completely given up (the class loader does not fall back to searching all JARs in the CLASSPATH) and the error InvalidJarIndexException to be thrown. To make things more messy, the order in which JARs are searched might affect how the class loader treats the INDEX.LIST file: the INDEX.LIST file of one JAR might refer to other JARS and if those referred to JARS are not in sync with the first JAR's INDEX.LIST file, the class loader fails with this InvalidJarIndexException error.
So (according to this StackOverflow question), it seems like this error can be thrown not only because a JAR file has a corrupt INDEX.LIST, it seems it can even be thrown on a JAR even if the JAR has a valid INDEX.LIST or legitimately is lacking a INDEX.LIST simply because a previously searched JAR has confused the class loader. (To put in another way, as things are, this exception might be thrown even for "innocent" non-corrupted JAR files due to offenders elsewhere on the system).
So, after writing a mere novel, here comes my main set of questions:
What is the best way to track down the precise .jar file for which each InvalidJarIndexException is thrown?
What is the best way check if a randomly picked .jar file has an INDEX.LIST file and if so, if said file is valid (that is, non-corrupt)? What tools exist for this task?
Is there an efficient way to automatically deduce the search order of .jar files? I can try to follow the CLASSPATH manually but to be honest, that is error prone and tedious.
Is there an efficient way to figure out what .jar file there is in a search order which might confuse the class loader to accuse innocent, non-corrupt .jar files later in the search to have incorrect INDEX.LIST files?
Disclaimer: I know I run old versions software (even if I have the latest updates of my Redhat 5.2 installed though) and I know a knee-jerk reaction for many people is to suggest that I don't put any effort whatsoever in debugging this but instead upgrade to a more recent version of Tomcat, Eclipse and Linux (Java is recent though). The reason I would prefer not to is that after looking into things, I've found it rather messy to do an upgrade or to try to install a separate modern Tomcat or Eclipse next to the RHEL5.2 provided Tomcat/Eclipse I use today. Also, I consider this kind of troubleshooting an opportunity to learn some useful nitty gritty details about Java and it's associated tools and features. Figuring out how the class loading works and what causes it to throw this InvalidJarIndexException on my system would be very educating!
(But if this troubleshooting fails, I'll seriously consider to use a modern Linux, Eclipse and Tomcat... I promise)

Take the following steps to diagnose the problem:
Add an exception breakpoint in Eclipse (it's the J with an
exclamation mark icon), and set it to halt for caught and uncaught
exceptions, of type InvalidJarIndexException.
Start debugging your program.
Eclipse will halt at your exception breakpoint, when the InvalidJarIndexException is thrown. Even without the source for URLClassPath, you will still be able to inspect the variables on the stack leading to the exception, including the name of the class that URLClassPath is attempting to locate. Knowing the name of the class should significantly narrow the list of JAR's you need to examine.
Perhaps you've locally added a new class to a package and the contents of that package are described by the index file in a stale JAR on your classpath?

Try Tattletale which is a good reporting tool for jars. What I have done in this case was to eliminate INDEX.LIST from jars one by one until I did not get InvalidJarIndexException any more