Osiris-Team

This is my idea of a perfect programming language, it's high level and compiles to C. Meaning it tries to give you high level constructs without sacrificing performance.

Let me know what you think!

There is a pretty basic compiler available which I developed 3 years ago that misses almost all features mentioned in the readme, thus you can mostly ignore that, since I want to focus more on the language spec, its recent changes and if its something you would use!

Yeah I proved myself wrong after adding more compiler optimizations.

I added some further optimizations and guess I was wrong!

Yeah, feel free to contribute / create a PR with a more C/C++ suited algorithm.

True but let's also not forget the unpredictability of stupidity in human developers which probably cause the majority of performance loss in any language.

Do they compare the second run of Java? Because using GraalVM native image does not really benefit from runtime info and optimization.

I just now created the repo for this purpose, hoped to reach some more experience C developers with it and prove me wrong.

Feel free to create a PR on the linked repo and prove me wrong.

To add some detail: I think that 99% of algorithms are faster in Java in their second run than in any other Language due to the better JIT compiler and optimizations that are possible. I am talking about the GraalVM distribution of Java and its latest version, but we might as well use other distros.

1JPM automatically resolves parent and child projects See project.isAutoParentsAndChildren. If true updates current pom, all parent and all child pom.xml files with the respective parent details, adding seamless multi-module/project support.

This expects that the parent pom is always inside the parent directory, otherwise a performant search is not possible since the entire disk would need to be checked.

1JPM helps porting your multi-module project Add JPM.java to your root project directory and add JPM.portChildProjects(); before building. This is going to download and copy the latest JPM.java file into all child projects it can find in this directory, and also run it to generate an initial pom.xml for that child project. The child projects name will be the same as its directory name.

A child project is detected if a src/main/java folder structure exists, and the parent folder of src/ is then used as child project root. Note that a child project is expected to be directly inside a subdirectory of this project.

Now project.isAutoParentsAndChildren will work properly, since all needed pom.xml files should exist.

Yeah I wish I could say build tools are simple. 1JPM was until I had to deal with transitive dependencies. The recursion going on there broke my mind quite a bit.

Running "clean build" should do the trick though, it will delete the ./build directory. Or do you mean the local maven repo?

I'm the original developer, decided to repost since there was some nice discussion I missed.

I think 1JPM is a wild idea and could be better in the future, but it's hard to compete with 20 years of development at release.

Ah a fellow tab-autocomplete power user.

Yeah, however once there are IntelliJ IDEA and VSCode plugins for 1JPM and I actually add some test cases, it should be usable.

Haha yes, if the IDE isn't happy, I'm not happy. But checkout the releases under github, there you can find the magical single JPM.java file you are looking for ;)

Its not really different. Except that bld seems to only support Java 17+, whereass 1JPM support Java 8+ and there is still a lot of Java 8 projects out there I guess.

Another difference is also that 1JPM is a single file, which has its advantages and disantwages, checkout the README for more details.

Wow 14 years ago! Thats great!

Those variable names are madness though haha. Or a single letter class is also pretty wild.

Happy to hear that! 1JPM is still pretty new and I expect there to be bugs, so if you have some free time and are interested in making this something usable feel free to contribute some day :)

Thats what 1JPM is also trying to prevent a bit, by leveraging the rigid structure of Java, or more accurately by proving an API that tries to satisfy noobs and power users.

Interesting, I guess the focus there is more on scripting. For 1JPM the focus is more Maven/Gradle similarity with Java build file.

Yeah I don't think there is much that can be done against this. Its a complex topic and simple solutions are basically just a dream.

Worked on transitive dependencies, and let me tell you, the version of such a dependency can be literally anywhere.

Haha glad to hear that! But really don't at the moment, the project is really fresh and I published a early access release to see if there was even demand, and I guess there is!

Contributions are welcome and I am happy to work on this project.

Right now I am using Maven to build 1JPM, or more accurately be able to do things in my IDE.

You won't need that pom.xml though since 1JPM is only dependent on Java 8.

Yeah, some kind people over Reddit also shared some nice repositiories like this one: https://github.com/takari/polyglot-maven

Which would have been great if I found it earlier, since it allows you to use maven but write Java.

The only edge 1JPM has compared to that project is that auto-complete and even more advanced features of your IDE work with it, since you can also move your JPM.java file into ./src/main/java.

Forgot to mention, its the "resolveDependencies" task.

Have been working the last 2 days (and nights) on this. It was a headache and it still doesn't feel like I implemented transitive dependencies correctly, but give 1JPM 1.0.3 a try.

Thanks! Yeah, simplicity and ease of use are definitely selling points.

I guess that makes sense, there are pros and cons to everything. I'm trying to designing the API in such a way that power users as well as noobs can have fun with it, which is a challenging task.

Well, thanks for reposting from Reddit! Got way more attention over here than there.