Import java file in Module Designer

Post Reply
NothanUmber
Posts: 45
Joined: Sat Aug 25, 2018 9:06 pm

Sun Dec 02, 2018 3:35 pm

The Module Designer is already saving a separate *.java file along with the *.vmod file - which is great, so I can edit the file in another IDE and check in the file to version control.

Haven't found an option how to import a *.java file again into Module Designer though. At least importing the "free text parts" would help a lot. Optimally it would reconstruct the entire *.vmod file (as long as the generated parts stay exactly in the syntax that the generator created/would create).
User avatar
nekomatic
Posts: 26
Joined: Mon Jul 08, 2019 8:52 pm

Mon Jul 08, 2019 9:33 pm

Yes, thats something I've been missing as well...
It seems there is a reason to disallow any modifications to the constructor, however preventing developers from importing the files back is not the only way to do so. This could be also done by parsing the external java file and validating it's syntaxt tree against some rules. Accessing AST is possible I believe since java 1.6. This may also allow to warn about many other legal in java patterns but disallowed in th emodule designer - like passing UI controls to other classes via properties, constructors etc...
xsatter
Posts: 1
Joined: Sat Jul 06, 2019 8:01 pm

Thu Jul 11, 2019 7:56 am

Totally agree, it seems to be no way make edits from an external IDE stick in Voltage Module Designer. This is a shame since the internal IDE lacks quite a few features normally found in virtually any Java IDE today (refactoring, search-and-replace (sic!)...). But the drag-and-drop support of visual components is very helpful, of course.
I've just started developing with VMD, but I suppose one way to go about it is to let the default java class be responsible for the GUI parts and have additional java files take care of actual calculations and processing. They can be created in your favourite IDE, employ standard Java syntax, tested using standard frameworks and added to the project under the Additional Java Files. One caveat is that when you make changes to the file in the external editor you need to delete it and reimport it in the Additional Java Files dialog... You would expect VMD to reimport them at compile time, but it doesn't.
Well, I suppose its is early in VMD's lifetime, and I hope improvements might be on the way.
User avatar
nekomatic
Posts: 26
Joined: Mon Jul 08, 2019 8:52 pm

Thu Jul 11, 2019 9:44 am

My guess is the reason for not letting people inject their code directly could be:
1. Making it easy to work with for people new to java and the dev at all - a full size IDE may be a bit intimidating for a fresh user.
2. Protecting the modules from any dangerous or troublesome code, like enforcing only one constructor with predefined body...
3. Keeping all resources in one file - again this is for the people new to java or coding at all
4. Preventing debugging tools from touching the internals of the application
There is also the benefit of the visual designer which is easier to be used for pople who are not used to code their user interfaces.

Apart from points 2 and 4 I don't see any reason why one shouldn't be allowed to use an external IDE for the whole module dev process.
Point 2. can be enforced by some code analysis build-time or reflection run-time. Code analysis requires more work but may catch any illegal code i.e. in the constructor's body.
Point 4. may be a bit diffcult but there are ahead of time compilators for java available which produce native binaries, those are harder to reverse engineer - note java classes can be investigated as soon as they are loaded into the memory, its not straight forward but also not impossible.

VM looks like a product which if well planned could be executed by a single skilled developer, there are probably more people working on the supporting infrastructure than the VM itself :)
Certain features may require extra people with apropriate skillset or at least some time for the current team to learn about the requred technologies... This is not something a company runing such small project can take lightly...
The point 4 could be also resolved by providing acces to extra tools ona a basis of an appropriate NDA, however maintaining a legal team which deals with any breaches may turn to be too much comparing to the benefits. Not to mention a breach may have inrevesable consequences for such project...

Anyway, after all that serius stuff being said, a way of seamless integration with a java build system would be a great addition to the feature set of the VMD :)
Post Reply