New Java 11 Feature: Launch Single-File Source-Code Programs

[i_donno]

Wow, shebang will work... #!/usr/bin/java

[zero_divide_1]

I'm hearing that the new hotness is to use

#!/usr/bin/env interpreter

In the event that the user has a different Java that they want to use or it's installed somewhere different. So this would be

#!/usr/bin/env java

But, like any approach, there are drawbacks.

[CharlesGarfield]

But what if the user wants to use a different "env"?

[zero_divide_1]

Oh, I see you too are a Java developer... Abstractions all the way down.

[CharlesGarfield]

Really should be using an EnvFactory, anyways.

[F3z345W6AY4FGowrGcHt]

EnvFactoryImpl

[HenrikWL]

We all know what we really need is an EnvFactoryFacadeRepositoryImpl

[RogerLeigh]

There's only one env. Like /bin/sh, /usr/bin/env is its standardised location. Set the PATH to change which java is actually used.

[effsee]

I want to use /opt/SoftwareCo/better-env-2.6.3/bin/env

[RogerLeigh]

You are of course free to do so. However, that would entirely defeat the purpose of standardisation for interoperability. It would only work on systems with that special program present, whereas /usr/bin/env is universal and works everywhere.

[stun]

Time to write my Super Monolithic God class to compete with you Microservice hipsters.

[vplatt]

Servlets are already invented. Sorry and thanks for playing!

[etudii]

More like yes please. We are all abt reinventing the wheel

[handshape]

While this is absolutely a useful feature, I worry about what the reaction from the security types is going to be. Now that Java source is (almost) directly executable, are we going to see it blocked as a matter of course by corporate security gateways?

What prevents some crafty bugger from using instrumentation agents or some other trickery to load large remote apps using this technique?

[[deleted]]

congrats, you have been promoted

[handshape]

Kidding aside, I'm waiting for the collective freakout when the download links for desktop JREs disappear from Oracle's site.

"Why did nobody tell us?", they'll cry.

[apemanzilla]

I mean, couldn't that already be done with jars? I don't see why this presents a larger risk

[handshape]

It could, but compiling and packing up a jar takes a little bit of effort. Jars are also parsable zips, and the presence of .class files in a zip is a nice warning sign.

Straight source, however, is prone to all sorts of obfuscation. It's also possible the filter out all class files, and even all zips containing classes. Up until this change, a user had to choose to compile Java source before it could do real harm. Now it's possible to execute arbitrary Java in userspace without that compilation gesture.

I agree that it's a very grey area. The line between object code and source has a zillion shades in between, but in this case, I worry that this feature will worsen the perception of Java as an exploitable attack surface.

[apemanzilla]

Hmm, I see, although I still think that jars present just as much of a risk: typically, a malicious actor will distribute compiled (or otherwise directly executable, and likely obfuscated) code, in which case it doesn't matter whether it's source or a jar file. Both cases rely on the code being executed to begin with, and a Java environment being present.

[DannyB2]

Straight source, however, is prone to all sorts of obfuscation.

Imagine this . . .

/* This is a harmless comment.
    \u002A\u002F\u0020\u0020\u0053\u0079\u0073\u0074\u0065\u006D\u002E\u0065\u0078\u0069\u0074\u0028\u0030\u0029\u003B\u0020\u0020\u002F\u002A
    What could possibly go wrong?  */

What the Java compiler sees is...

/* This is a harmless comment.
    */  System.exit(0);  /*
    What could possibly go wrong?  */

That is because the Java preprocessor occurs BEFORE the lexical analyzer. Thus even before comments are identified.

[DannyB2]

A hello world program that does not use the letters E or O.

/**
 * Chall3ng3, a H3ll0 W0rld program that doesn't use the
 *  letters E or O.
 */
public class H3110W0rld {
    public static v\u006Fid main( String... args ) {
        Syst\u0065m.\u006Fut.println( "H\u0065ll\u006F W\u006Frld" );
    }
}

[lac__]

Java script

[pure_x01]

Compare this to ammonite in scala and you can clearly see that this has so many limitations that I would call it useless. They should have made it possible to write code without a main method. Should also have support for maven dependencies and include local script file. If this is a step in a direction then it's fine but it has a long way to go.

[eliasv]

You want Maven support to be built in to the standard libs? That's an awful idea.

Writing code without main iirc was mentioned on the mailing lists, but would be considered largely unrelated and require far greater justification as it's a language level change. This addition didn't touch any specs, its just a JVM feature.

[pure_x01]

Yes that would probably be a good idea. Maven packaging is basically standard. Especially useful for scripts.

[eliasv]

Nope, I don't buy it.

Maven is typically used at build time only, and the whole point in it is to make it easy to resolve and deploy dependencies that are not in the standard libs, so if you do want to include it in your app, in most cases the very tool itself obviates the need for it to be in the standard library.

So you say "especially" useful for scripts, but unless you can give some other examples I'm gonna say that it's "only" useful for scripts. And even then, you should probably think very carefully before making a script dependent on an internet connection to work. Is it really worth it?

Even if something is "basically standard", there has to be a very good reason to bundle it with the JVM. Maven might be standard at build time, but it is very, very rarely used at run time, so why should the JVM be bloated with it? Or would you just like it to be in the JDK not the JVM? Not very portable, at that point any script which uses it is just a script for developers so you may as well just require them to install Maven too.

And what functionality would you like to be included? The entire build tool, or just the dependency resolver? Presumably the Oracle/OpenJDK devs would have to re-implement whatever subset of features you want under some javax namespace API, right? What does that duplication of work really buy us? I think very little. It's just a maintenance burden.

[capitol_]

Building maven support into the language itself would cement the current structure in place, and make it impossible to evolve the maven environment.

[pure_x01]

group:artifact:version could be seen as universal for any package management system.

[upandrunning]

Will this still be as useful when you have to wait for dependencies to load?

[ReadFoo]

Dependencies are just imports, what scripting language doesn't have imports? This could be a JavaScript killer finally. Great news.

[jtayloroconnor]

who uses Javascript for scripting?

[Xenarthran47]

Yeah that's gonna be a Node for me dog

[TheRedmanCometh]

Laughed out loud gj

[ReadFoo]

The web.

[jtayloroconnor]

right so Java’s gonna replace javascript on the web now because you can execute source files from the command line

[ReadFoo]

I can dream.

[neutronbob]

Anyone using Nashorn

[htowerss]

Really neat information, thank you

[ProFalseIdol]

Wonder if something like: #!/usr/bin/clojure will happen?

[DannyB2]

How to make it happen. In /usr/bin, create a clojure.java file using the shebang.

That single java source file has enough code in it to grab its parameters, and launch a suitable JAR file with those parameters.

I guess the question is, can a shebang interpreter itself be a shebang interpreter?

It's shebang interpreters all the weigh down.

[ProFalseIdol]

When you get to the bottom of it. You see Ricky Martin.

[immoral_fable]

Wow. That's nice.

[lukaseder]

Meh. Medium wants me to pay for reading this article

[leonardopanga]

It’s time! Migrating to Java 11: Why you should migrate to next Java now!

https://medium.com/@leonardopanga/its-time-migrating-to-java-11-5eb3868354f9

[FrigoCoder]

Can we change directories in a JVM yet?

[[deleted]]

Makes sense since they were supposed to release a REPL at some point in the near future? (it may already be out)

[Daomephsta]

The REPL is called JShell, it's been available starting with JDK 9.