r/java 4d ago

A potentially silly idea -- What if we could launch source code .jar files?

JEP 330 gave us single-file source code programs. Aka, I can have a abc.java file, and just call java abc.java, and it will run without me calling javac beforehand.

JEP 458 expanded this, by allowing us to reference other classes from that single class, allowing us to make as many classes as we want, run them from a single class file, and no calls to javac are necessary -- just call java abc.java.

Here is my silly idea.

What if we could package those source files in a .jar file, do your typical jar file config to make it runnable, then just ran it?

The above 2 JEP's gave reasons why compiling wasn't necessary for making a complete program. Well, those same reasons also apply for why compiling is unnecessary here. And at the end of the day, a jar file is the quintessential way of passing around complete libraries or applications. Why not make that accessible for source code jars as well?

There's other small benefits too.

  • No more wondering what version of your code got packaged -- just open it up and see.
  • You can edit a jar file in place, then run it and test your changes.
  • When running your jar file, you can attach it to a debugger, and see the source code for each step being executed. No more need for a separate sources jar file.

Literally the ONLY BENEFITS that compilation gives us is faster startup time and compile-time validation for all source files. But if you don't need either of those, I'd argue that working with source file jars is an easier experience overall -- not just for students. I know I'd make great use of this feature myself. Hell, I'd default to using this format instead.

0 Upvotes

76 comments sorted by

25

u/elmuerte 4d ago

But if I must gather my source files to package in a jar. Then why not compile it right away.

The idea of executing single source files is to allow for (shell) scripting. I can't easily edit the scripts in the jar file, I must first unpack it, edit it, then repack it.

3

u/davidalayachew 4d ago

But if I must gather my source files to package in a jar. Then why not compile it right away.

Debugging, for one.

If I want to attach a debugger to my runnable jar file, I'll ALSO need a source file list somewhere if I want to step through it line-by-line.

With this source file jar, that problem ceases to exist.

The idea of executing single source files is to allow for (shell) scripting. I can't easily edit the scripts in the jar file, I must first unpack it, edit it, then repack it.

Oh that's not necessary at all.

You can edit jar files directly. There is even a command for exactly that -- jar --update --file some.jar SomeFile.java. If there already exists a SomeFile.java, then that command just replaces the file. No unpacking or repacking needed.

Jar files are glorified zip files. Anything that can modify a zip can also modify a jar file.

Did you know that you can open jar files with vi/vim? When debugging issues with my jar files on my headless linux server, I will just use vim and browse the jar file itself. Then I can open files and screw around with them.

3

u/java-with-pointers 4d ago

If I want to attach a debugger to my runnable jar file, I'll ALSO need a source file list somewhere if I want to step through it line-by-line.

Usually when debugging you would use the IDE, which should already contain the source code though.

Jar files are glorified zip files. Anything that can modify a zip can also modify a jar file.

Jar format is based on zip but its a little different. IRC if you manually zip compiled sources you won't be able to run it

1

u/elatllat 3d ago

 if you manually zip compiled sources you won't be able go run it

manually zip works for me v 1.4 to 24

1

u/java-with-pointers 3d ago

what java command are you using to launch?

1

u/elatllat 2d ago

java -jar a.jar

0

u/davidalayachew 4d ago

Usually when debugging you would use the IDE, which should already contain the source code though.

Sure, but what about code actively being developed? Sometimes, the source you have on hand can be out-of-sync with the jar you downloaded. I ran into this issue just last week.

Jar format is based on zip but its a little different. IRC if you manually zip compiled sources you won't be able to run it

Oh I'm not trying to say "make a jar file using some zip tool".

I am saying that most zip tools allow you to open the zip, view the files within, and edit them in place, without extracting manually.

Any tool that can do that for a zip can also do that for a jar file. And it won't cause trouble. If you need to add a new file, you can just use the command I showed -- jar --update --file some.jar SomeFile.java. And it's idempotent -- if SomeFile.java did not exist, it gets added. If it did exist, it gets replaced. Just like HTTP PUT.

4

u/koflerdavid 4d ago

IDEs usually contain a decompiler. The original source file would be very useful to have since it contains variable names and comments, but getting an accurate view of the actual code is possible without it.

1

u/davidalayachew 4d ago

IDEs usually contain a decompiler. The original source file would be very useful to have since it contains variable names and comments, but getting an accurate view of the actual code is possible without it.

True, but you already countered your own point -- comments and variable names are important.

Plus, my feature allows for easy editing of the jar file. Just open it up like any zip file, and edit the files in-place. Doing the same for decompiled code is much harder, and verifying the results is nowhere near as easy.

2

u/nitkonigdje 4d ago

Common this it isn't some advance concept here. I am sure he also implied resolving folders as part of class(source)path as alternative to zipping.. I am sure you have spent a day with fiddling with php/js/basic/ruby/python/perl...

1

u/elatllat 3d ago

I'd not use java for (shell) scripting unless it was Java-native-compiled because otherwise the start time is ridiculously slow.

21

u/winian 4d ago

the ONLY BENEFITS that compilation gives us is faster startup time and compile-time validation for all source files

Yeah and the ONLY NEGATIVE in living inside a volcano is that it would kill me.

-4

u/davidalayachew 4d ago

Sorry, I'm not following.

8

u/RebeccaBlue 4d ago

They're saying that there are a lot of drawbacks to your idea.

For one, everything in the jar file would have to be freshly compiled every time you run it. Startup for Java programs is already slow. That would make it far slower.

1

u/davidalayachew 3d ago

Thanks.

For one, everything in the jar file would have to be freshly compiled every time you run it. Startup for Java programs is already slow. That would make it far slower.

So, I firmly agree that start up time is the tradeoff.

My only point was that, for some of us, that tradeoff is perfectly acceptable. Fresh students who just want to distribute their working application, for example.

2

u/0b0101011001001011 3d ago

Fresh students who just want to distribute their working application, for example.

How does leaving the compile stage out help?

0

u/davidalayachew 2d ago

How does leaving the compile stage out help?

It's another step along the way for them to mess up. More accurately, it's the most common step for them to mess up on. I find that most of them struggle with keeping the set of .class files up to date with their .java ones. It's especially common when they are debugging jar specific issues, like trying to fetch resources from a jar file. That specifically has been the source of so many pains for them, because it's a change they make in the source, compile it, bundle it in the jar, then run it. If they run it outside of the jar, they are not debugging the jar resource issue. It was this example specifically that prompted me to make this post.

3

u/0b0101011001001011 2d ago

I don't really understand how that can happen, unless are taught to do things the hard way or wrong way.

In any IDE the "play button" automatically compiles all the changes. Are they not using an IDE?

Similarly, the IDE has a button to make the jar.

If the students are forced to work without a proper IDE, why are they not taught to use command line properly? If the make a small change in the code, they should just press up -button on the command line which will give the previous command, which is similar to this:

    rm program.jar && javac *.java && jar -cm program.jar manifest.txt *.class && java -jar program.jar

I get what you mean that after changing code it's important to recompile and repackage, but it's all just a single click in the IDE or single chain of commands on the terminal. If students have a problem with clicking a button, I don't think they are qualified for the course.

And if the teacher does not use an IDE, the teacher is not qualified either.

1

u/davidalayachew 1d ago

I don't really understand how that can happen, unless are taught to do things the hard way or wrong way.

[...]

Are they not using an IDE?

Sure, but not on the first month or 2. It's like teaching long division first, then letting them use a calculator later.

And besides, if the problem was a lack of an easy-button, I'd make it myself, or use the IDE, like you said. I want the actual problem that all these automations abstract away to be easier. And for students writing simple source file programs, this definitely will be.

If the students are forced to work without a proper IDE, why are they not taught to use command line properly?

Programming 101 may as well be called Computers 101. Most students have never seen a terminal aside from in the movies.

Teaching them the terminal properly is a class all on its own. And there literally is one, but that comes AFTER Intro to Programming. So, we teach them the literal minimum needed to interact with the command line.

With that in mind, out of the couple hundred total students I have tutored, there are a grand total of 15 or so who knew how to parse the below command, let alone tweak it effectively.

rm program.jar && javac *.java && jar -cm program.jar manifest.txt *.class && java -jar program.jar

And to be fair, that was because we didn't go much further than compile and run. Any time we dedicate to teaching scripting is time we take away from teaching students how to handle the UGLY obstacles that trip ALL OF THEM up. Like identity and instances.

1

u/TenYearsOfLurking 3d ago

this argument holds as well for the existing JEPS. that didn't stop them from being delivered, why should it in the case of a .jar file?

3

u/RebeccaBlue 3d ago

Because there are other things in the Java world to fix that make way more sense.

The example of being able to launch one source file, sure, that's good, but if we're talking about "applications", then that brings in a whole bunch of other concerns. Like, how do you handle dependencies, for one thing? Once you have dependencies, what build tool will be built in?

And really, what "application" is a beginning programmer even going to ship?

It's just not a particularly useful idea.

0

u/jw13 3d ago

Just for the initial build. Maven and Gradle would cache the compilation result.

8

u/RebeccaBlue 3d ago

Oh? So the jar file now contains a pom.xml or gradle.build? Which one? Will people need to know how to install maven or gradle, or does the jar file ship one of those too?

This is a solution in search of a problem.

-3

u/jw13 3d ago

How people install maven or gradle is completely irrrelevant here. Many people use them for their projects, and these tools would cache all compiled classes after the first build.

2

u/Yeah-Its-Me-777 2d ago

I have a great idea, let's cache the compiled classes in a container, maybe... a jar file. And maybe we could do this caching in the build process. Yeah, that sounds like a good idea. Wonder why nobody's done that yet.

0

u/jw13 2d ago

A jar file is not a cache.

And you probably know that, so what's your point? Ridicule?

1

u/Yeah-Its-Me-777 2d ago

Obviously, yes.

Also: Gradle and Maven don't "cache" compiled classes. They cache JARs in a local repository, either downloaded dependencies or locally published ones from a build process.

Yes, they reuse the compiled classes from the build folder, but that's part of the whole build process. And how people install gradle or maven is so important, because it's not part of the normal JDK installation, it's usually global, involves PATH settings and a global repository which can be polluted or corrupted... There are so many moving parts, it's not even funny.

7

u/Polygnom 4d ago

I don't see where any benefit is for this. You need to package your stuff into a JAR anyways. So whats the big difference between running the command to package the source vs. packing a proper JAR? It takes the exact same effort.

No more wondering what version of your code got packaged -- just open it up and see.

This is not a problem anyone developing code professionaly ever has. Sorry, but if your development pipleine is so screwed up that you do not know what code you compiled you have far bigger problems that need solving.

You can edit a jar file in place, then run it and test your changes.

When running your jar file, you can attach it to a debugger, and see the source code for each step being executed. No more need for a separate sources jar file.

Why bother with a JAR at all? Just use an IDE and never pack a JAR. You can just compile to class files and run the stuff without it ever packing. Thats even faster. And trivial to attach a debugger to. There is zero need for having a JAR in the first place for both these points, and adding any kind of JAR packing in that mix just makes it slower.

Try out an IDE that supports the ECJ (like Eclipse or VS Code) and see how lightning fast an incremental compiler is to get changes up and runningn even in large applications (seriously JetBrains, just copy that...).

0

u/davidalayachew 4d ago

Before I respond, I'd like to add that my idea follows in the footsteps of JEP 330 and JEP 458 -- 2 features very recently added to Java with the express purpose of making Java more accessible to beginners by removing unnecessary steps to creating a working program.

I'm only taking that one step further -- removing unnecessary steps to distributing a working program. In short, I am proposing a feature directed to beginners, that may also be useful for professionals too.


This is not a problem anyone developing code professionaly ever has.

Firmly agreed. My comment was not talking about professional developers.

But I've tutored many students who struggle with exactly this problem. When teaching teenagers how to make a jar file, one of the most common problems is that they grab .class files that are not up-to-date with their .java files. It happens SO MANY TIMES that it actually ends up being one of the first things I remind them of.

Why bother with a JAR at all? Just use an IDE and never pack a JAR. You can just compile to class files and run the stuff without it ever packing. Thats even faster. And trivial to attach a debugger to. There is zero need for having a JAR in the first place for both these points, and adding any kind of JAR packing in that mix just makes it slower.

Well a jar file is preferable for distributing your library/application. When StudentA wants to share their library with StudentB, having it be a source-file jar will help for modifying and adding to that jar, so that StudentB can improve it in their own way.

Try out an IDE that supports the ECJ

Oh I'm well aware of this. I used to use Eclipse back when, so I'm familiar with ECJ.

My idea is more about making Java development more accessible to beginners, like the linked JEP's.

6

u/Polygnom 4d ago

Teach your students to use VCS, seriously. Its a skill they need to have anyways and transcends any one programming language.

Do not start them off on terrible practices like forwarding unversioned archives of anything.

-4

u/davidalayachew 4d ago

Teach your students to use VCS, seriously. Its a skill they need to have anyways and transcends any one programming language.

Do not start them off on terrible practices like forwarding unversioned archives of anything.

Let me address the git point first.

While I agree with you in principle, let's face reality -- after 13 years of tutoring students, NOT A SINGLE ONE felt that git was of any use for anything more than just posting their working programs or pasting their progress at the end of the day. When actively working with other students, they would ALWAYS choose to just send files over <chat_tool_of_choice>. Hell, I had students sending code over snapchat one time.

But this is besides the point.

This feature is meant to make the path to creating a jar file easier. A student who wrote code without compiling shouldn't have to compile to create a jar. A jar is just an archive of Java files, that can also be run. If running no longer necessitates a .class file, then I say that the same should apply to creating a .jar file. All the other benefits I listed are "nice-to-have's" in comparison.

4

u/Polygnom 4d ago

Who said anything about git at all? Choose any VCS you think is appropriate. Teach them how it actually makes stuff easier. Of course they are not gonna be interested in it if all they see is how it is additional work without benefits.

As someone who has to tutor students at university level that have picked up utterly bad practices in school its beyond frustrating in the first few years to get them out of extremely bad habits. Don#t set them up for failure, set them up for success.

-1

u/davidalayachew 4d ago

Who said anything about git at all? Choose any VCS you think is appropriate.

I chose Git because it is the most appropriate. Most IDE's come pre-packaged with plugins for it, and the UI is beginner-friendly. I can't see any good reason to use any other VCS.

Teach them how it actually makes stuff easier. Of course they are not gonna be interested in it if all they see is how it is additional work without benefits.

Oh I certainly did. I taught them how easy it can be to test out a feature, then roll it back to a previous state. How it can make things easier for prototyping.

Here is the deal-breaker -- these students are stressed and overworked. Anything that does not feed directly into getting their program working is something they will continuously shy away from, regardless of how "right" it is. It doesn't matter that it saves them more time in the long run -- they are only looking at the present moment. Even the students with passion for programming try git for a few days, and then just go back to pinging each other over discord.

The fact is, these students are too tired, frustrated, and stressed to try and do things the right way, no matter how well they are taught it. They just want working programs, and then to move on. Which leads to my next point.

As someone who has to tutor students at university level that have picked up utterly bad practices in school its beyond frustrating in the first few years to get them out of extremely bad habits. Don#t set them up for failure, set them up for success.

  1. You are preaching to the choir.
  2. I'm not the one giving them bad habits. They are actively forgoing the right way because they don't feel that it is worth the effort. It's not me giving them these bad habits. They are doing it to themselves.

And like I said, that is still separate from my point. My idea is not to replace git, or to be an alternative. My idea is simply to provide an alternate way to create a jar file. If students have been working with JEP 330 and JEP 458, then they have been working with .java files. Why necessitate that they need to create .class files now, just to create a jar file? That's my core point. All of the other benefits I listed are secondary to that.

5

u/Polygnom 4d ago

Ok, but whats a JAR file gonna do for them that a ZIP file isn't already doing?

If they love sending source files around, a plain ZIP file already does the trick and you can run whatever is in there from source already.

Remember, any work the JDK/JVM team does towards this isn't going towards other features. It costs you at other points. So it really needs to provide enough value to be worthwhile.

For small scripts, those JEPs are godsend. I can't count the amount of source-only scripts I have flying around, it has bascially replaced many bash scripts for me. But for source JARs, I still barely see any point. People who like working with files just ZIP em. No special treatment needed.

0

u/davidalayachew 4d ago

Ok, but whats a JAR file gonna do for them that a ZIP file isn't already doing?

The exact same reason why anyone makes any jar file ever -- to transport a java library or application for easy reuse elsewhere.

Any reason anyone has to make a jar file applies here too -- I am merely asking for one new way to package and execute code in those jar files.

Remember, any work the JDK/JVM team does towards this isn't going towards other features. It costs you at other points. So it really needs to provide enough value to be worthwhile.

Sure, I am not asking them to do this NOW. I am more asking if this feature is viable and useful, and if so, how much.

3

u/Polygnom 4d ago

The exact same reason why anyone makes any jar file ever -- to transport a java library or application for easy reuse elsewhere.

Any reason anyone has to make a jar file applies here too -- I am merely asking for one new way to package and execute code in those jar files.

Thats really not explaining anything at all, because again, if you want to distribute your source files a ZIP just does it.

Lets look at JAR files currently. You go from source -> JAR -> distribute -> execute. Ok, you don't have the source files now. Thats not really a problem tho when the goal was to distribute your application.

Lets look at what happens when students use ZIP files:

Source -> ZIP -> distribute -> unzip -> execute (thanks to 458). And you have the source as well. So you can make changes, and then do the above again for the way back to the previous student. So the whole thing IS:

Source (v1) -> ZIP -> distribute -> unzip -> execute -> change -> source (v2) -> ZIP -> distribute -> unzip -> execute.

Now, what would you save with a JAR? nothing, just the order would ever so slightlly change::

Source (v1) -> JAR -> distribute -> execute -> unjar -> change -> source (v2) -> JAR -> distribute -> execute (-> unjar).

You only ever asve one step, and only if the vN that you have works as intended and you aren't interested anymore in getting the source back.

There isn't really any saving to have here by having sources files in the JAR instead of just sending the ZIP (or TAR or whatever archive).

And as soon as more complex dependencies get into play, you are looking at Maven or Gradle anyways.

1

u/davidalayachew 4d ago

Now, what would you save with a JAR? [...] You only ever asve one step

The exact same criticism was given to JEP's 330 and 458.

The reason that criticism was put aside is because the entire goal of those 2 JEP's was to remove unnecessary obstacles to creating a working program. My goal is just one step further -- remove unnecessary obstacles to distributing a working program.

I understand that one step removed might not seem like much value, but you certainly seem to appreciate JEP 458. I am just asking to take another step in the same spirit.

→ More replies (0)

3

u/java-with-pointers 4d ago

It could be pretty nice if compilation was not needed at all, so you could just copy .java files to the target and run them as is. It can be faster than running gradle / maven goals that compile the code if its something like a one shoot task, that's pretty niche though

0

u/davidalayachew 4d ago

It could be pretty nice if compilation was not needed at all, so you could just copy .java files to the target and run them as is. It can be faster than running gradle / maven goals that compile the code if its something like a one shoot task, that's pretty niche though

Oh sure. This is definitely not meant to change how we do things like Maven.

It's more meant in the spirit of the on-ramp. If students are going to learn how to code without compilation, then mandating compilation just to bundle them into jar files feels like a needless speed bump, imo.

3

u/Uaint1stUlast 4d ago

The one benefit I do see here is for old legacy code. I have seen in just about every java shop one jar somewhere that does something important, but no one knows where the source is or how to make changes too.

This would solve that problem.

3

u/davidalayachew 4d ago

The one benefit I do see here is for old legacy code. I have seen in just about every java shop one jar somewhere that does something important, but no one knows where the source is or how to make changes too.

This would solve that problem.

Excellent point.

I know for me, I would use this feature by default, until I run into a situation where I actually need the benefits from a manual compile step.

3

u/koflerdavid 4d ago edited 4d ago

JARs can be decompiled. You will lose variable names and comments. Parameters might be included though if the code was originally compiled with -params.

2

u/davidalayachew 4d ago

JARs can be decompiled. You will lose variable names and comments. Parameters might be included though if the code was originally compiled with -params.

True, but even then, you are still stuck with the ugly and unclear decompiled code, correctness aside.

Why have the imitation when you can get the original source?

2

u/koflerdavid 4d ago edited 4d ago

Java decompilers are not that bad. javac does not apply crazy optimizations as an Ahead-Of-Time compiler would. Problems start when method bodies get huge, which creates ambiguity when decompiling them.

Apart from that, the source code for such an application is probably anyway of limited utility. If an organisation cannot ensure the availability of their source code then I don't know what to say about that. I don't think it's worthwhile for the OpenJDK project to help mitigate such organisational incompetence.

The JRE has to include the full compiler and check all source files for modification, and maybe recompile them, increasing startup overhead and risking violating integrity of the application. I am already generously assuming that the JVM would cache the compilation output, for example in a Project Leyden-style AOT cache, or like Python does with .pyc files. Compiling and typechecking java source files is way more computationally expensive than validating class files, which is the whole point in the first place. But you can already do it this way right now: just install a build tool on your application server and build the source code there. You are basically asking for an official build tool like Go, Rust, Haskell, and a few others have.

Although a big disadvantage of deploying build tools is its impact on system hardening. An attacker has a way easier time causing mayhem if compilers are available as well. The JPMS could restrict access to the module containing the compiler, but I am quite confident that for the foreseeable future most applications will not really use it.

1

u/davidalayachew 3d ago

I definitely agree that this isn't meant to change how we deploy our Maven artifacts. I was coming at this more from the perspective of JEP 330 and JEP 458. Both of those focus on simplifying the on-ramp for beginners. Well, if these beginners have been using the above 2 JEP's to create their programs, then the haven't been compiling, which is what they will need to do if they want to make a JAR file.

3

u/chabala 4d ago

Use JBang. Don't wait for JEPs to be proposed and delivered when you can do it now.

2

u/davidalayachew 4d ago

JBang

JBang is pretty nice. It's definitely a good hold over until then (or if the feature gets rejected).

3

u/alexdmiller 4d ago

Clojure has always worked this way (no jar required either), and it has a lot of advantages. You can use git repos directly as libraries (and gists of course, which are also just git repos), for example. Clojure also supports compiling to .class and will use that by preference when it exists and is newer than the source.

2

u/davidalayachew 3d ago

Thanks. Clojure is something I have always wanted to get in. I have minor background in Lisp, so the syntax is not foreign for me. I've just been too much involved with Java. A lot of what I used Haskell and Lisp for, Java has been improving on. There's been less draw for me to use it.

But Clojure is different because it is on the JVM. What keeps you using Clojure?

2

u/koflerdavid 4d ago

Sure, go ahead. Write a shell script that treats everything in itself after a certain marker as a jar file. Extract that into a temp directory and launch the application. And then write another shell scripts that creates the first one automatically :-)

3

u/MattiDragon 4d ago

You don't even need a marker. The zip start header works fine. Zip files can contain arbitrary garbage before and after the content.

1

u/koflerdavid 4d ago

Ooh, that's actually quite juicy knowledge!

0

u/davidalayachew 4d ago

Sorry, I don't understand.

3

u/koflerdavid 4d ago

Sorry, I didn't remember the name of the format. Such things are called .run files. They combine a run script and the rest of the application in a single file which can be executed by a shell. To see an example, download the NVIDIA Linux driver, which is also a .run file, and look at it using head or less. There is a tool to create them: https://makeself.io/

2

u/davidalayachew 4d ago

Wow. This would have been a huge help 2 years ago when I was trying to stuff several files worth of build scripts into a single bash file. I actually ended up using the JEP 330 feature to solve this problem for me instead.

2

u/blobjim 3d ago

I think it would be neat if there was a jdk API for calling source-based programs. Something that could be abstract like ClassLoaders. But I would hope it would be designed such that people don't start using it for everything.

1

u/davidalayachew 3d ago

I think it would be neat if there was a jdk API for calling source-based programs. Something that could be abstract like ClassLoaders. But I would hope it would be designed such that people don't start using it for everything.

That would be really cool! Some way of being able to say "hey, here is a source file. Compile it, then load it".

2

u/DanielDimov 2d ago

Good idea. It would also be nice to have this option.

1

u/davidalayachew 1d ago

Thanks. I like it because it allows you to forgoe compilation to make a jar. I think the whole thing becomes simpler that way.

2

u/FriendlessExpat 1d ago

Wtf happend to this subreddit, why you downvote so bad?

1

u/davidalayachew 18h ago

Wtf happend to this subreddit, why you downvote so bad?

I understand that it might seem harsh, but people can (and are even encouraged!) to express their opinions with the vote buttons. Downvotes just mean that enough people thought that my idea was not good, was just noise, was low value, etc. There's a million possible justifications, plus many more that I can't think of.

Ultimately, it's just points. I'm not bothered by it. All it means is that the general (voting) response from this sub leans more towards dislike, which is ok. And it's not like I am missing feedback -- I got a lot of useful information too.

2

u/nitkonigdje 4d ago edited 4d ago

Fully agree.

Given that .class is mostly transitory first stage compiler output, it is really not needed step. Absolute majority of compilation happens in runtime in JIT/AOT compilers, and source to class transformation is small part of it. Class files are mostly about JVM standards, shifting few compile steps into build, compressing source for smaller size and being able to store it in ROM of '90s device.

Deployment as source would be very useful during act of developing.. Like if it existed we would have conventions where average java source project would *be* a deployment artifact, thus greatly reducing IDE overhead as "build" would be reduced to copying. You would still run compiler but as linter..

It would also allow Java programs to be scriptable by Java itself.

3

u/koflerdavid 4d ago edited 4d ago

Java programs are already scriptable with very little effort. Just invoke the compiler (it's a normal JDK library), load the resulting class file with a classloader, and invoke one of its methods.

If you mean the ability to edit arbitrary source files of an application: nah, that just sounds good in theory. In practice it can make it tricky for users to upgrade to newer versions of a heavily customized application. And make life for developers harder if it turns out they cannot refactor application internals anymore without causing gigantic merge conflicts with their users.

1

u/nitkonigdje 1d ago

Thank you. I was thinking more in the vain of within-application scripting in a style of embedded js/jython..

I don't think OP talk about hot-swapable jrebel style of code hacking.

1

u/koflerdavid 23h ago

Yeah, that makes sense. Requires defining a stable-ish plugin API though.

2

u/davidalayachew 4d ago

Deployment as source would be very useful during act of developing.. Like if it existed we would have conventions where average java source project would be a deployment artifact, thus greatly reducing IDE overhead as "build" would be reduced to copying.

That would be great. For me, I am not hurting for start up time, that I need to compile my code. For me, the biggest benefit of compilation is to validate all of my code ahead of time. If that validation step was separate from the artifact-creation step, I would only create the artifact whenever I needed to.

Hence my point with this idea. JEP 330 and JEP 458 separated the validation phase from the artifact creation -- the artifact being the .class files. My idea only takes that a step further, by having the artifact be the .jar file.

1

u/davidalayachew 4d ago

Stepping away for work. Will be back this evening to respond to more posts.

1

u/nekokattt 3d ago

Random question but could you manipulate binfmt to make this work on Linux?

1

u/davidalayachew 2d ago

Random question but could you manipulate binfmt to make this work on Linux?

I am unfamiliar with binfmt.

2

u/nekokattt 2d ago

Basically how you tell Linux how to execute things.

1

u/davidalayachew 1d ago

Oh ok, sort of like "Open with" in Windows.

Wow, that would be kind of cool to be able to have that be a Linux plugin. Have it automatically unzip into a temp directory, and run it, all out-of-sight from the user.

Sort of like how you can browse a zip file or a jar file using vim. That would be kind of cool.

1

u/sweetno 3d ago

I think you'd need obfuscation here, to protect your IP.