I'm using a Java lib within my Scala project. I want to call a specific static method adjustLib of that lib as early as possible and for every possible starting point of an execution (e.g. before runing the "main" App and before executing tests) to achieve the desired behaviour.
One solution would be to place this statement at the very top of each class, that might be executed (applies for all classes extending App and for all tests).
However, if someone implements a new, executable class but forgets adjustLib, things might get weird.
Is there any chance to define an object or something similar, that executes this adjustLib statement in a "static" manner every time anything in the given project is executed?
Ive been looking at the Arithmetics example that comes with xtext and I stumbled upon the Calculator.java class under the org.eclipse.xtext.example.arithmetics.interpreter package but I cannot find any reference to it.
I understand that this class is used to walk the AST and evaluate the expressions but who is calling it and how is it registered?
I have a similar example which I am setting up from scratch and using the arithmetics as an example, however I dont know how to register the AST walker so that each time a tree is visited the particular method is triggered as in the Calculator class.
If you right-click the Calculator class (either directly within the Java Editor or in the Package Explorer) and select References -> Workspace you will get listed all occurrences of the Calculator type. You'll see that it is used in the ArthimeticsValidator and InterpreterAutoEdit types, where the latter is responsible for actually evaluating an expression within its evaluate method. From the InterpreterAutoEdit class, you can work your way up and see that it is registered via the ArthimeticsUiModule.
I have a use case where I need to create a class based on user input.
For example, the user input could be : "(Int,fieldname1) : (String,fieldname2) : .. etc"
Then a class has to be created as follows at runtime
Class Some
{
Int fieldname1
String fieldname2
..so..on..
}
Is this something that Scala supports? Any help is really appreciated.
Your scenario doesn't seem to make sense. It's not so much an issue of runtime instantiation (the JVM can certainly do this with reflection). Really, what you're asking is to dynamically generate a class, which is only useful if your code makes use of it later on. But how can your code make use of it later on if you don't know what it looks like? For example, how would your later code know which fields it could reference?
No, not really.
The idea of a class is to define a type that can be checked at compile time. You see, creating it at runtime would somewhat contradict that.
You might want to store the user input in a different way, e.g. a map.
What are you trying to achieve by creating a class at runtime?
I think this makes sense, as long as you are using your "data model" in a generic manner.
Will this approach work here? Depends.
If your data coming from a file that is read at runtime but available at compile time, then you're in luck and type-safety will be maintained. In fact, you will have two options.
Split your project into two:
In the first run, read the file and write the new source
programmatically (as Strings, or better, with Treehugger).
In the second run, compile your generated class with the rest of your project and use it normally.
If #1 is too "manual", then use Macro Annotations. The idea here is that the main sub-project's compile time follows the macro sub-project's runtime. Therefore, if we provide the main sub-project with an "empty" class, members can be added to it dynamically at compile time using data that the macro sees at runtime. - To get started, Modify the macro to read from a file in this example
Else, if you're data are truly only knowable at runtime, then #Rob Starling's suggestion may work for you as it did me. I'll share my attempt if you want to be a guinea pig. For debugging, I've got an App.scala in there that shows how to pass strings to a runtime class generator and access it at runtime with Java reflection, even define a Scala type alias with it. So the question is, will your new dynamic class serve as a type-parameter in Slick, or fail to, as it sometimes does with other libraries?
I want to build a simple 'rake' style command line tool that will allow me to define tasks in scala (that can optionally take additional command line arguments) that will be automatically loaded and accessible through a single main() method, to provide a single point of entry and minimize generating lots of wrapper scripts.
An example of what I'm looking for is Jersey, which will automatically load all annotated classes in a specified package and create REST endpoints. What's the right way to do this in scala? Basically, I just want to end up with a collection of instances of every class in a
package with a given annotation (which all have a Task trait or are a subclass of Trait, etc.)
I have an assignment to code several methods in Scala. The methods will be encapsulated in an object that has no main method. The professor gave us a JAR file that contains an interface (my object implements this interface) as well as a sort of pseudo test object that performs various assert statements against each of my functions. This object also does not contain a main method.
Now in Intellij I simply had to declare the dependency on the JAR in the classpath, and it runs fine. Eclipse is giving me trouble though because when I go to define a Scala application run configuration it specifically asks me to name the class that contains a main method, and there is no main method.
I am assuming that I might be choosing the wrong project type for this type of set up, but I am inexperienced with this and I would appreciate any advice you might have for running something like this in eclipse.
Thanks.
I would either:
just write an object with a main method which calls the test object, or
start a Scala interpreter in your project (from context menu, under Scala).
Preferring the first approach, because it's faster to repeat tests after a modification.