Include AspectJ support to VS Code - visual-studio-code

In my current project I'm working with Java, Spring Boot and .aj files. However, the main problem about work with AspectJ is that there are not a lot of IDEs that supports this feature.
Eclipse (and i think that netbeans too) supports the AspectJ language because I've used it in the past. However, I've worked with IntelliJ and Visual Studio Code IDEs during the last years and I don't really want to come back to Eclipse (or Netbeans). :)
Also, I know that the Ultimate Version of IntelliJ has support to AspectJ. The problem is that you must have an IntelliJ license to use it.
https://www.jetbrains.com/help/idea/enabling-aspectj-support-plugins.html
I started to create a new language server for the Visual Studio Code to manage the .aj files. I'm following this guide.
https://code.visualstudio.com/docs/extensions/example-language-server
The .aj files are now correct colored and shows a valid syntax!
However, I'm getting errors in the Java code. Check this schema about the AspectJ description:
As you could see, I have a .java file called Point and I want to have some methods divided in some .aj files. When the project is compiled, I'll have just one Point.class that includes the methods clone(), compareTo(), etc.
Also, another possible use is that if my .java class implements some interface, I'm able to implements the methods in a .aj file.
Problem: I'm not able to see my Java project without errors because the .java files and the .aj files are not "synchronized", so the .java class says that needs to implements some methods although they're defined in the .aj file.
Someone could help me with tips about language server development?
Regards,

I can't help you with VS Code <> AspectJ integration, but I could recommend a work-around with your issue. If my understanding is correct, you get errors because the methods declared through inter-type declarations by your aspects are not visible to your java code.
In that case you might try to create Java 8 interfaces with default methods that declare and implement those methods. I would try to get rid of the aspects altogether and work with just interfaces with default methods, but if - for some reason unknown to me - you really need to use aspects to implement those methods, you can still leave your default methods empty and move the implementation into the aspects. This way you don't need to use inter-type declarations anymore, so VS Code integration might work better.

Related

Netbeans + Codename One - Avoid importing packages or classes not suitable for CN1

I'm using Netbeans IDE. It's quite annoying and it's a cause of errors the import of Java packages and/or classes that are not provided by Codename One. (Codename One use its own implementation of a subset of Java8 and it cannot support the full Java API).
For example, sometimes Netbeans imports automatically wrong packages (such as "java.awt.BorderLayout" instead of "com.codename1.ui.layouts.BorderLayout"), other times it shows me methods and Javadocs that are not available in Codename One.
Is it possible to force Netbeans to show me only packages, classes, methods and javadocs that are supported by Codename One? It could be useful to avoid errors.
We'd love to but unfortunately the only way NetBeans allows you to do that is if you build your own Java language package. That's what some other plugins like NBAndroid did AFAIK but when we implemented the plugin we didn't want to create something too complex.
If NetBeans supported a "bootclasspath" option for the JDK it would have solved everything. It does have support for plugging in an alternative JDK which can be a micro-profile but because we don't comply with the micro-profile spec I'm not sure if that will work.
At times, NetBeans suggests to import more than one package from the drop-down list. When you check carefully before pressing ENTER this might avoid importing the wrong package.
I use NetBeans for quite a while with CN1 and faced the same problem at the beginning.

Output folder of the Kotlin compiler in Eclipse

The Jetbrains Kotlin compiler in Eclipse outputs to a hidden folder inside the Eclipse compiler plugin. This hidden folder is then made available through the Eclipse Kotlin classpath container.
In bndtools we need a normal file system folder since bnd can run both from the file system as well as in Eclipse. Since the folder is a linked resource there is no known way to translate it outside Eclipse.
Anybody knows how to tell the Kotlin compiler to just output it in the bin folder?
Currently, this is not possible in the Kotlin Eclipse plugin.
To make it possible that Kotlin code can be used from Java, Kotlin plugin produce so-called lightweight class files to this folder. These class files do not contain bodies for methods and they are stored in memory.
Actual class files, that are used to run an application, are being built only before launch and they are produced to the default output folder. For now, we cannot produce class files on each save reasonably fast as there is no incremental compilation in the plugin yet:
Feel free to upvote for this issue.
From the short analysis of the code of Kotlin plugin, it looks like the proper method is KotlinCompiler.compileKotlinFiles. It is being called in two contexts:
KotlinBuilder.build — this is the one called on the project build; it makes a call stack trick (or rather a hack...) to check if being called from the LaunchConfigurationDelegate, and depending on the results, either compiles whole project (via its own private fun compileKotlinFiles), or just makes stubs in memory.
KotlinCompilerUtils.compileWholeProject — this is in fact being called from 1.; nice static method, perfect for abuse until the problem is correctly solved in the plugin. :)
So, I'd use the method from 2. wrapped in a similar way as compileKotlinFiles from file in 1.

IJavaProject without Eclipse Environment in JDT

I have an exported Eclipse Java Project in my server and I want to be able to compile the project and use ASTParser with JDT.
I'm able to compile the project using BatchCompiler, however it runs on console and gives me PrintWriters instead of an array of problems and errors. Also I want to be able to use proposals in Eclipse and BatchCompiler didn't built for this purpose.
Therefore I tried to use ASTParser, it can be used with either char[] or ICompilationUnit. CompletionProposalCollector and org.eclipse.jdt.internal.compiler.Compiler.Compiler needs ICompilationUnit so I have to create an ICompilationUnit which only can be created by an IJavaProject (https://dl.dropboxusercontent.com/u/10773282/2012/eclipse_workspace.pdf) in order to be able to use these features.
It seems the only way to create IJavaProject is to use ResourcesPlugin.getWorkspace(), however it returns java.lang.IllegalStateException: Workspace is closed. on my computer and it seems the reason is that the program that I coded is not an Eclipse plug-in.
Is there any way to create IJavaProject without Eclipse environment?
From the comments, it looks like you are trying to do more than just parsing, you actually want to get some form of content assist.
I'm afraid that you're asking for too much. There is no simple way to get the power and flexibility of JDT outside of a running Eclipse instance (believe me, I've tried). There's no simple way, but if you are brave and strong willed, you can one of try following:
Run a headless Eclipse on your server that works on top of an actual workspace. This would be the easiest to implement, but would be the most resource intensive and least flexible way of doing things.
Use the jdt core jar, and create alternate implementations of the IResource hierarchy, and the parts of JFace that are used by the the parser and the CompletionEngine. This would likely be the most feature-rich way to go, but also the most brittle. I can't guarantee that this would work as you may need to create some very complex stubs for internal Eclipse non-API classes.
Avoid the CompletionEngine and the ASTParser entirely and just use the batch compiler. You would then need to provide an alternate implementation of org.eclipse.jdt.internal.compiler.env.INameEnvironment. This implementation would be able to find types, files, and compilation units in your actual project structure. You'd need to reimplement support for content assist, but this would most likely work reasonably well.
I am actually fairly interested in doing something like this (but I lack the time to do it). If you are seriously considering creating a headless JDT that can run on a server, feel free to ask for more information. I am quite familiar with JDT internals.
I've had a similar problem. Here is how to use ASTParser without Eclipse (it just needs the core JDT JAR on the classpath): http://blog.pdark.de/2010/11/05/using-eclipse-to-parse-java-code/

How to add jars properly to a eclipse bundle

I got a little problem. I want to use hibernate in an eclipse rcp. (i'm new to osgi and eclipse rcp). So I added the jar into the plugin-project folder and the build path and the bundle build path, but when I try to use hibernate from my bundle, it crashes with a ClassNotFoundException.
What is the proper way to do this?
Pls look at eclipse buddy policy. This might help you if you are facing class not getting loaded because of osgi classloading.
Hibernate, and many other classic Java programs (ab)use dynamic class loading to to connect the different parts. They classes they use are read from a file and then loaded with Class.forName. This is fundamentally not-modular since these classes are by definition implementation classes, which should be hidden.
Since OSGi is a modularity framework it puts fences around a module (a bundle) and refuses to load anything that is not properly exported and imported. So if Hibernate does its Class.forName it will run right into this fence, as it should be to get the advantages of modularity.
Eclipse Buddy policy is like a huge hole in this fence, moving things back tot he bad old classpath: linear search. With a buddy policy, Eclipse will just start searching if there is a class somewhere that has that name. Since this ignores versions, you can no longer rely on proper version handling. The good news is that it works most of the time. The bad news is that you loose privacy and when it does not work you get weird errors.
With Hibernate, only solution is to not use the text file setup but use the API and give Hibernate the actual classes. In those cases Hibernate will use the class loader of those classes and that works. In OSGi, as long as you follow the Java language rules there are no problems.
To handle the kind of problems that class loading hacks address OSGi uses services.

How do I get support for GPB in Eclipse?

I'm trying to use Google Protocol Buffers in my project and I'd like to have some tooling support from Eclipse. In particular, I want Eclipse to call protoc every time I make changes to the .proto files and then rebuild all code that depends on the generated code.
I tried to set up a Custom Builder but it keeps bugging me with errors I don't understand, most often it complains that the .proto file is not on the path given by --proto-path, which it should be by all I can tell. Also, because I use ${build_files}, Eclipse passes all changed files to the compiler (instead of those that I have configured to trigger the build).
NetBeans seems to have a protobuf-Plugin, but I can't find one for Eclipse. Is there one?
Theres a protoclipse plugin on googlecode, which is in the initial stages:
http://code.google.com/p/protoclipse/
Not sure if there is a builder, but I did find a plugin for syntax highlighting for protocol buffers.
You can define an external builder on the plugin that invokes an ant task. It is an ugly kludge, but until there is a better solution this may serve your purposes.
In practice, syntax highlighting turned out to not be that important, I hardly edit these files, and they tend to be very small. Maven and the m2eclipse plugin handle the building side of things great.
I recommend using Google's "Protocol Buffers Development Tools". It is a plugin for Eclipse that features automagic regeneration and error checking, among other things. It's available here: http://code.google.com/p/protobuf-dt/ .
While this question is close to other Eclipse plugin for working with protobuf, answers here are different.
Well, yes, if you use maven/gradle to invoke protoc (Protobuf compiler), than you may need no Eclipse plugin at all.
Colorizing editor helps for long file or with many comments. Know there are 2 editor plugins for Eclipse.