I found this importer for .x files in the jMonkeyEngine SDK plugins: http://jmonkeyengine.org/groups/contribution-depot-jme3/forum/topic/directx-to-j3o-converter/?topic_page=1&num=15 , and I downloaded/installed it successfully via the Tools -> Plugins menu.
But I'm not sure how to use it. I tried adding a model to my assets folder, then right-clicking it in the SDK and choosing "Convert to j3o Binary", but this accomplished nothing: no dialogs popped up, and nothing seemed to change at all. My code still generates a runtime warning stating that it doesn't know how to load a .x file.
P.S. I posted this question as a reply on the linked thread as well. So far, no responses, so that's why I'm posting here, but just a heads-up in case someone replies there in the near future.
Update: A user replied to the thread, suggesting I check to see if any errors are being thrown (a little red error icon in the bottom-right corner of the screen). Sure enough, there was, and the error message was the converter complaining about not being able to find the dwarf.jpg texture. So I moved the texture into the Models folder next to the dwarf1.x model.
However, the conversion process is still behaving the same way, except that the error icon doesn't come up. In other words, nothing appears to be happening now, and no error messages are being thrown. I don't see any .j3mo file having been created anywhere, and my code is still causing a runtime exception that complains about not having a loader for .x files. (Note: I saw the filename typo in my screenshot, "dwarf.x" instead of "dwarf1.x", and have since corrected it, so that is not related to the problem at all)
Ok, found out the problem. The converter was still not finding the texture, even though it had stopped reporting the error about it. I had to rename the texture to match the model's filename exactly (except for the extension, of course), so "dwarf.jpg" became "dwarf1.jpg". Note also that it has to be in the same exact folder: in my case, I put it in the project folder/assets/Models/
Related
Situation
I'm trying to build a JavaFX App and for GUI I use SceneBuilder to produce fxml files for the different roots to use. Then I launch the App and at some point I'm trying to load some fxml file with new FXMLLoader(App.class.getResource("myFXML.fxml")).load() and set it as root on the scene on the stage.
Issue
99% of the times the loading has no problem at all and everything works as intended, but that 1% will fail and prevent the fxml loading without stopping the App but only throws the warning bellow.
WARNING: Caught 'java.lang.ClassCastException: class java.lang.String
cannot be cast to class javafx.scene.paint.Paint (java.lang.String is in
module java.base of loader 'bootstrap'; javafx.scene.paint.Paint is in
module javafx.graphics#18 of loader 'app')' while converting value for
'-fx-background-color' from rule '*.list-view' in stylesheet
jar:file:///C:/mysystem/.m2/repository/org/openjfx/javafx-controls/18/javafx-controls-18-win.jar!/com/sun/javafx/scene/control/skin/modena/modena.bss
The fxml that causes it most of the time is the one with a ComboBox in it but i don't think this has to do with it since it happened anywhere.
Important the warning is not consistent as well, at the pre-last line instead of *.list-view other times says *.button as well, but i am doing the same action to test it.
Reproducing the Issue
Reproducing is not consistent at all, the warning is descriptive and seems that the problem is on a JavaFX file (mentioned in the warning) and not in something I wrote. Thus I can't find a consistent way to reproduce it or handle the exception or something.
Tried so far
Removing the ComboBox (just in case)
Searched the internet to find nothing about it
Re-installing JDK did nothing
Note
I know there is much more information I can provide that may help but I'm exhausted right now. Maybe will add with edit later on.
Long Story Short
I was doing the FXML loading (new FXMLLoader(App.class.getResource("myFXML.fxml")).load()) and scene.setRoot(...) on another Thread and not the FX Thread. So make sure with Platform.isFxApplicationThread(); (as mentioned in the comments) that the operation happens on the FX Thread to ensure expected behavior.
Important
The answer is not complete, it is a placeholder for anyone searching it currently and this resolves the issue.
Improvements
I will try as soon as possible to update the question with more information and reproducible example. Also I will with the help of the comments continue the research to find solid explanation for the issue. In the mean time feel free for edits or post new better answers.
I'm having somewhat of a strange problem with NetBeans. I'm creating a program in Java that has multiple packages in it. I created 2 new classes for the project, but immediately afterwards I realized that I put them in the wrong package. So, I clicked the name of the class in the projects panel, dragged it to the appropriate package, and released. NetBeans then asked if I wanted it to refactor my code. This was the first time I've done this so I decided to preview it. It looked fine (just changed the package name) so I went ahead and moved the 2 classes over, allowing NetBeans to refactor them. This is where my problem comes in.
I realized while coding that NetBeans is no longer underlining the errors in my code, yet-to-be-finished lines, etc. It is instead just italicising the font. I thought this was strange so I decided to test it out in another class and for some reason everything worked fine in the other class. It turns out that NetBeans is only giving me this strange behavior in the 2 classes that it moved and refactored.
So I looked online and saw that you could change what NetBeans does with errors in Tools -> Options -> Fonts & Colors -> Syntax -> Category Error. I figured this would't work because this was obviously a preferences page for "everything." My settings were fine, so I changed the error setting, applied the change, and then changed it back to try and "re-force" the error highlighting preferences. Now NetBeans doesn't underline errors anywhere, and only italicises them.
In addition, the syntax highlighting preferences for everything (default, character, comment, etc.) that did not already have any effects color or effects setting now show "Effects: Wave Underline Effects Color: Red". And if that wasn't weird enough, they don't even "red underline." I've tried closing and reopening the classes and restarting NetBeans but nothing's working.
I took screenshots but unfortunately I can't post them because I don't have 10 Rep. Did I break my NetBeans? Thanks in advance.
EDIT: Even though my error setting were correct:
Effects: Wave Underline
Effects Color: Red,
restoring the default NetBeans settings for Fonts & Colors fixed my problem. Must have been some sort of strange bug?
Maybe is too late, but a have de same issue.
Try with Windows>Reset Windows.
In my case only happens in one class.
I had exactly the same problem with NetBeans 8.1 pressing 'Restore' and restarting worked for me.
After looking through dozens of other SO questions involving these two classes, I've come to the conclusion that this might be a new one.
The code in question involves Eclipse (kepler), Maven, and GeoTools - specifically, a copy of ImageLab from their tutorial, which I've stripped down partially to play with the Style classes. I changed one bit of code to create an RGB style to replace the grayscale style the example uses - and suddenly I get a ClassNotFoundException on this snippet:
Layer rasterLayer = new GridReaderLayer(reader, rgbStyle);
If I put a breakpoint there and step into that constructor, I immediately get the CNFE on org.geotools.data.FeatureSource. This is a fairly frequently used class, though, in the gt-api jar, and it's already downloaded and sitting in my Maven Dependencies folder. In fact, I can even stick this in above that line:
FeatureSource<?,?> source = null;
...this compiles happily, and it still throws a CNFE on that constructor after it. It finds it, and then it can't find it??
That CNFE is being caught and eaten silently, apparently, if I just run the app without using debug mode - it later throws an NPE when it finds that Layer's style object is null.
I've tried restarting Eclipse, and running Project>Clean several times - same problem. gt-api.jar (specifically, gt-api-12-RC1.jar) is in the build path for that project. I can't step into the URLClassLoader, to see where it's looking; or at least, I don't know how.
Can anyone please explain this bizarre behavior, or better, suggest a solution? Alternately, can anyone tell me how I might get a better look at what the URLClassLoader is doing, or what it thinks its classpath is?
I have written a customer annotation processor to generate various source files, wrapped in an Eclipse plugin. As part of this process it also logs various errors and warnings using the usual call ProcessingEnvironment#getMessager().printMesssage(Kind, String, Element).
I have been testing the processor by debugging the plugin in Eclipse. In the launched sub-instance of Eclipse the processor all works as expected - source files are generated, picked up and interpreted by the compiler as desired. Any compiler (i.e. non-custom) errors in the generated and non-generated appear in the editor, Problems view etc. as expected.
However I am seeing a lot of inconsistencies in terms of how custom errors and warnings appear. The behaviour I see is as follows:
If no Element is specified all messages appear in the Error Log under type Info, regardless of the Kind specified when logging the error.
If a message is of Kind NOTE it always appears in the Error Log under type Info, regardless of whether or not an Element is specified.
Otherwise, if an Element is specified errors and warnings intermittently appear in the Problems view and in the editor; sometimes they don't appear anywhere. They never appear in the Error Log, whether the Kind is ERROR or WARNING
As per the emphasis above, the real issue is item 3 - that under certain situations I simply cannot get errors to appear in the editor despite being logged on valid elements. In fact, I have managed to reliably make errors appear and not appear by simply changing the name of a particular generated source file.
Of course the issue is not the filename itself, but it is certainly the case that generating the class with a name that matches references already in code causes errors to get hidden, whilst generating it with a different name (or not at all) causes errors to show (as well as all the regular compiler errors caused by a missing class). The strangest thing is that there is nothing fundamentally different about this generated class compared to any of the others (of which there are many), although it is unique in its structure and how it is referenced. It also reasonably long (around 400 methods), but artificially shortening it did not make any difference. Other generated classes also have existing references in the code and don't suppress errors.
Unfortunately I have also not yet had the time to test if this issue occurs when the Eclipse plugin is deployed (i.e. running in a 'real' instance of Eclipse), or indeed if the issue occurs when calling javac explicitly or invoking a Maven build.
Without posting the full code of the plugin I don't expect anyone to be able to help directly, but I am very open to any suggestions or advice if anybody has experience issues with annotation processor-generated errors. It seems to me like a bug in Eclipse, but I have not been able to find any reference to it online. I also cannot find any errors in the .metadata/.log files of either the underlying Eclipse instance or the launched sub-instance of Eclipse. Finally I have ensured that there are no Exceptions suppressed or reported in the annotation processor code.
Eclipse version details:
Version: Luna Service Release 1a (4.4.1)
Build id: 20150109-0600
Any help appreciated and many thanks in advance :)
If a problem/error has to be shown in the Eclipse Problems view, you need to create a Marker on the particular resource (file/folder/project). Please see the following links on how to create the Markers in an Eclipse Plugin:
https://wiki.eclipse.org/FAQ_How_do_I_create_problem_markers_for_my_compiler%3F
https://www.eclipse.org/articles/Article-Mark%20My%20Words/mark-my-words.html
In terms of how the custom errors/warnings appear, the Problems view (or the generic MarkersView) is completely flexible to show/hide certain elements. Have a look at the "Configure Contents..." menu in the Problems view to get more idea.
I've come across quite an odd problem with eclipse.
I was working on a project and I right clicked on a method call declared in another class and used Eclipse's handy find declaration in project (saves me quite a bit of scrolling) to run a search for that specific method declaration. Right as it should my search pane pops up with a link to the method declaration. So I click the link, the other file the method is declared in is opened automatically, and poof the Java file I had searched from disappears from my editor tabs.
So I say to myself, "damn this old version of eclipse (Indigo) has some bugs...now I've got to go reopen my file and get back to my spot...GREAT!". But when I open the file, it is treated like a plain text file. All the text is the same color, and the outline won't work!!!
So I solved the problem whilst I was typing the above up and decided to post the answer since it isn't a nice clean solution..and I doubt one exists.
Okay so file wasn't being recognized by eclipse..
So I open the file and do a Save As, and save it under another name in the same package.
Then, I went to my test code and right clicked on a method call that was declared in the file that eclipse had buggered up, and went to search for declaration in project.
Sure enough two results popped up, one in the newly saved as file, and one in the old one.
I clicked on the old one, and still plain text...no difference.
But then I clicked on the new one, and my highlighting was back!
So then I just deleted the old file and refactored.
I think somehow eclipse made the file disappear without properly closing it...just my guess, glad I resolved this nice and quickly, hopefully anyone who has the same issue can be helped by this.
This happened to me a couple of minutes ago. Trying to close/open the projet, restarting eclipse did not work for me.
The steps I used were:
Pick another Java file (same package) right next to the bogus one (make sure syntax highlighting works on this one)
Choose 'Save As' and override the bogus one.
Verify that the bogus one now has proper syntax highlighting
Use git checkout -- to retrieve you original file
Et voilà !