I am new to Spring and just now learning to use it in a piece of legacy code. If I use bad syntax (as in I mistype a bean name or I use the wrong syntax to construct things like enums) then the code will compile fine.
This makes sense, since they're just XML files loaded at run-time.
For me, this is a big issue because my service can take up to 5 minutes to run, even though it compiles instantly. And there is no need for this, because all of the syntax errors can be known before the service is run. I shouldn't need an exception to know about it.
In Eclipse, is there a plugin or feature I can use to have compilation fail if my Spring syntax is invalid?
Sure. Take a look at STS (Spring Tool Suite) - it is a n Eclipse special bundle for working with Spring. It has the context XML validation plugin and many other goodies.
Related
I was thinking of building a tool through which we can have Named Parameters in Java 8+. I am looking for approaches on how to move forward with this. Here's what I have thought of so far,
Writing a compiler plugin which rewrites the method arranging and matching the parameters. In case it is not able to do so, it will throw a well defined exception. Caveat is I would also need to write extensions for IDEs so it does not show as a compile error in IDE.
Writing a buildscript which does the same as above, but does it pre-compilation. We still have the same problem as above and on top, I would have to write for multiple build systems.
Use AOP and use #Named annotations to specify names. IntelliJ and Eclipse both support aop compilers so IDE support should not be an issue. However this adds an extra overhead of adding AOP framework as a dependency.
There might also be some way to leverage Kotlin over here, but I am still exploring that.Looking forward to some ideas that I am completely unaware of as well as feasibility of what I have suggested.
I am not sure if opening a JEP would help as a proposal in 2015 was shot down.
FYI, I am not looking for answers/comments like why not switch to Kotlin. The point of this question is to know how feasible it is to implement this in Java, without changing the JDK itself.
I've started working with jHipster on a recent project which is a tool you can use to autogenerate the full stack of a REST api application using a Spring Boot back end. Which should save a great deal of time writing boilerplate code...
Unfortunately, at my work we have coding standards to adhere to in the form of a set of CheckStyle rules. Any code that does not adhere to these rules causes the build to fail. What I am experiencing at the moment is that this autogenerated code is failing the CheckStyle rules in a large number of places. Currently I am handling this by manually trawling through the code fixing each of the issues.
I can't help feeling in the back of my mind there must be a better way of doing this e.g.:
Configuring the IDE (intelliJ) to ensure the generated code matches the CheckStyle rules. This is certainly possible when coding directly into the IDE.
Configuring jHipster to be aware of the CheckStyle rules before autogenerating the code.
Running a script afterwards which can automatically fix any CheckStyle failures. (I'm sure this must be doable!)
It would be good to hear if anyone knows what the best way to address this issue might be and if anyone has done something similar in the past.
Suppress violations on all auto-generated files as it is out of your control.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter
If you have auto-generated code inside a file with non-generated code that you maintain manually, use comment suppressions.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionCommentFilter
You shouldn't be styling code you don't write for this exact purpose, you aren't writing it and some utility is and it wasn't built to your style specifications. If you generate the files again, it will undo any manual changes you made.
I am looking for a solution that can be run on a continuous integration server (TeamCity) which seems to rule out IDE specific solutions like the externalization that is built into eclipse.
I need to generate warnings when strings are found in the java source files, unless they have been somehow flagged (by comment or annotation) as not requiring internationalization, eg the // $NON-NLS-1$ comment for eclipse.
The code is built using maven in teamcity.
I have not been able to find existing solutions or any ideas on how a custom solution might be hooked into either maven or teamcity (note I am not hugely familiar with either so could be overlooking something fairly obvious).
It seems that you need some specifically crafted Static Code Analysis tool.
I am afraid that no such thing exists yet (or I should say no such thing is available for public use...). I am not sure if you would be able to create warnings from the tool though. I know it would be possible with Gradle, but integrating Gradle task with Java code is not an easiest thing to do (BTDT).
Maybe some simple HTML report would do? In this case, you can simply use Scanner with regular expressions that matches all the strings literals... That is unless you'll find exclusions (another RegExp) in the same line. That's pretty basic thing to do.
I have just started with annotation based programming in Java. I was using xml based setups (hibernate) for configurations.
In annotations we have to write annotations within the java files, right. So, if we need to change something, then we would have to edit the java file, compile it again? Is this the correct way that I am understanding?
I read this question regarding the advantages of annotation in hibernate. But my question is not limited to hibernate.
UDPATE (Should not have used write once run anywhere in question)
In case of xml based-config, we just make changes and restart the app that it right?
But in case of annotations, we would require to again re-compile, re-deploy and re-start the app. Isn't this a disadvantage?
No absolutely not!
To reflect the changes made in your source code you have to compile and run the code again and is true for all programming languages. Only use of annotations or xml configuration files is to ease the project setup, debug and running.Even if you have xml/annotation for your project(Ex Spring or Hibernate) you have to recompile the project to reflect your changes.
"write once run anywhere" paradigm is that when we compile any java code it gets converted into bytes code which can run on any OS/Platform. All you need is the JVM installed which actually understand and runs the java code.
Updated Question Answer : Again the answer is no! It is not at all a disadvantage. In face it is a feature to prevent writing more code(So that you can concentrate more on your business logic). You have to choose the right combination for your project. For example recently i worked on Spring and I used both xml configs and annotations. xml config has the configurations that are user configurable where as annotations are mostly used more for flow control. For example annotation in my case dictated what to be executed before a bean is create or after. Same is the case with most of the annotations based code. It is used to tell JVM that specified functionality is for specified condition but the data required for processing is obtained from xml configs.
I don't know much about Hibernate, but needing to recompile after changing the source doesn't break "write once, run anywhere", which is intended only to refer to the (theoretical) platform independence of a compiled Java application.
write once run anywhere: means you can run in it on any platform without having to redo anything for a particular platform.
It does not mean that you write once, and if you have to change something, it will work without recompiling your classes.
After looking at the Play! framework I find it really productive that the development server that it comes with automatically is able to compile .java files and show the changes, immediately. There's no hot deployer scanner that runs every tot seconds or so. The compilation happens when you hit refresh and it's extremely faster than my incremental mvn package. How do they do this?
I would like to know, well because I'm interested in knowing, but also because I don't want to use the entire Play! framework for my small project. I'm only interested in their development compilation process because I would like to adopt it :).
Any ideas?
I was reading about this just this morning. It actually takes your changed source files and uses the Eclipse Java Compiler (ECJ) internally before spitting out the compiled files to the built-in dev server.
The thing is, you probably don't want to go to the effort of wiring the ECJ into your "small project".
You can definitely approximate it though - the trick is to not do a mvn package, instead you want to be dropping the changed .class files into your webapp's exploded warfile directory on the filesystem.
If you're not tied to a particular app server/container, have a look at the Eclipse Jetty Plugin - looks like it's what you need, and Jetty is quick
JDT -- Play! uses Eclipse JDT to compile and load classes dynamically. Much the same way you code in Eclipse and you see an error or warning messages as soon as you type in something not desirable. See ApplicationCompiler class.
You may also want to look into JDT.
Play uses the Eclipse compiler to compile code at run-time.
Take a look at the following class, that is used by Play to perform the necessary compilation at run time.
https://github.com/playframework/play/blob/master/framework/src/play/classloading/ApplicationCompiler.java
The way they do it is by using a custom classloader that will detect changes to source files, use the Eclipse Java Compiler to compile the files and then hot swap the appropriate classes in the JVM. If you are looking for something similar, checkout ZeroTurnaround's JRebel
it is not free, but well worth the time savings when you need to redeploy a large project.
I'm not a Play developer however Struts2 is also capable of this but though the struts2-spring-plugin. Since the class reloading is provided by Spring it might be possible to use this spring feature by any project.
http://struts.apache.org/2.2.1/docs/spring-plugin.html
Search the page for "Class Reloading".