file extension - change from *.java to *.jsweet

[cincheo]

file extension - change from *.java to *.jsweet

[renaudpawlak]

I think I see what you want to do, however it might not be as good of an idea as it first appears. Let me explain why.

JSweet programs are pure Java programs. This is on purpose, because we can then benefit all the tooling available for Java, including of course the compiler, which will verify types. In IDEs such as Eclipse, it is essential that JSweet files are recognized as Java files, so that all the default Java tools apply to them (search, refactoring, code assist, etc). JSweet can be used without any plugins in Eclipse or IntelliJ, because it is recognized as Java. So, you can just use your favorite Java IDE and a Maven, Gradle, or any build tool you want. I guess that if Sublime has a plugin for Java, then it would apply to JSweet.

If we change the extension it is likely that the Java compiler will not even accept JSweet files as compilation units, so we would loose all the benefits of being in Java.

That said, I like the idea of being able to easily recognize a plain Java file from a JSweet file. It could indeed be useful to write plugins that can apply specific JSweet behavior on JSweet files and leave alone the Java files (for example). I have been playing with the idea but so far I did not find any satisfying solution. Maybe some sort of annotation or specific comment in the file would do the job. Maybe a specific metadata file?

In any case, I believe that we need a little bit of time to understand all the use cases and potential implications when writing plugins for various environments. For instance, if someone wants to write a plugin for Sublime, we would have some actual feedback on what needs to be done and what would be the limitations of the current approach.

Don't hesitate to discuss this subject with examples and concrete input.

[mokross]

I see your point(s)! :-)

What about using the file extension *.jsweet.java? At least on the organisatorical level!

Perhaps(!) this would leave the available Java tool chain intact and could give plugins the chance to register for a file extension... just an idea...

[renaudpawlak]

Interesting proposal! I will keep it in mind because I might encounter a case where it could be useful. Note that one of our projects, we have made the choice to put all the java files in src/main/java (maven standard) and all the jsweet files in src/main/jsweet. Afterall, this convention would do the job too.

I propose to keep these as proposals as long as we don't have a clearer and more extensive set of use cases and feedbacks. Nothing should prevent the programs to conform (or not) to future conventions if we decide to have official conventions. In general, conventions appear because a lot of users share a common use case and thus find them convenient. For example, a Sublime plugin could follow your *.jsweet.java convention that would end up being used a lot (and thus end up being "officialized"). But for now, we don't really know what is going to happen :)

[renaudpawlak]

Actually, I thought of another related use case. Github recognizes JSweet project as majoritary Java projects... For instance, take the https://github.com/cincheo/jsweet-examples project, if you click on the bar that shows the source code types, it says:

Java 70.4% HTML 16.8% CSS 12.8%

This may be confusing to people, because JSweet is not actually Java. In that case, declaring a new type of files to Github would be useful. But I am not sure how Github file type recognition works.

I was also thinking that your proposal probably cannot work because Java expects that the class name and the file name match. For instance, a C.java file must contain a main class called C. I am not sure that the Java compiler would be happy if we insert an intermediate extension in the file name.

[lgrignon]

I think it is a bigger problem than it seems because actually JSweet files could be plain Java files. Actually some simple Java files (such as DTO) could be shared between pure Java projects (e.g. a server project) and a client JSweet project. Thus, it seems complicated to "flag" a file as a JSweet file, it would be more like a "JSweet compliant flag" which seems strange to me.

Anyway, if you choose to flag your JSweet, I would rather recommand that you use annotations, so the transpiler could rely on it to know which files need to be transpiled and at the same time constrain the developer to put the annotation (otherwiste file wouldn't be transpiled).
This behaviour may be an option of the transpiler, such as onlyTranspileAnnotatedSources or maybe something clearer ;)

Thanks again for the proposal.

[renaudpawlak]

This proposal will not be on the roadmap for now. Probably too complicated and has a lot of unpredicatable outcomes.