Hacker News Reader

Comment by freedomben | Hacker News Reader

This is definitely an improvement for Java, but it leaves me with a few thoughts as someone who has done Java professionally at times, but also professionally lived in other ecosystems including C++/Qt, Python, Ruby, Golang, and of course node/JS.

1. Setting up a project is still a pain in the butt. Tools like Gradle are a nice improvement over Ant (and some would say maven), but still most people don't even understand them. You have some serious reading ahead of you if you want to set something up that isn't already templated somewhere for you. You can lean on an IDE for sure, and for most Java devs this is probably a no-brainer. I'm weird in that I don't like magic. I prefer to know what the tool is doing on my behalf, and the Java IDE world is so complex that it isn't practical to learn that unless you're in the ecosystem for years. Then dealing with weird exceptions from the JVM can be maddening.

2. The Java world moves slowly. It could reasonably be years before many shops transition to Java 9, when you would actually realize the benefits of this in your work life.

3. So much Java runs on the server side anyway, where executable size and entrypoint doesn't really matter that much. Because of this, it may only be a small subset of Java shops that really get into Java 9/Jigsaw and iron out the bugs, and create tools/tutorials for others.

View on HN

None of these points are valid:

1. Dependency management is probably a lot easier with Maven than with C++ or Python. Hope that needs no reference...

2. No idea why, but Java is backwards compatible. So not updating to the latest version is only laziness.

3. Having much smaller containers or virtual machine disk sizes should lower your AWS/Google/Cloud... bill a (little, but whatever) bit and therefore make your CFO happy...

You're wrong about point 2. Java has backward compatibility but there are a few exceptions. On top of that, the library's that come bundled with the jdk have a few backward incompatibilities of their own. These might be small things to fix when your codebase is small, but for enterprises with codebases of millions of lines, these issues turn an upgrade in a major challenge.

Apart from that, there is another reason why companies don't upgrade and that's because they are locked to a certain java version by their application server. Upgrading to a new java version would require upgrading the application server as well, which would cost a lot in terms of licensing and which would introduce some risks and overhead of its own.

I can confirm all of what you said. That's the reason application servers AND big monolithic applications NEED to die and they need to die right now. Just have clear defined boundaries for services, deploy them inside a docker/rkt whatever container; just let whatever legacy application run with java 1.4 until you replace it completely.

Well, that is a good thing: You still can buy regular support for Java 6, which was released more than 10 years ago. So if you really think updating your monolith to Java 9 is worth less than paying for that support, you can do so. Not all software generates such a huge margin that updating it would be a viable option for your business. How many other languages provide such long-term support for releases that are a decade old, even if you were willing to pay for it?

Not saying that monoliths needs to die, but you won’t get defined boundaries just by going with microservices/Docker. And from personally updating a “monolith” to java 9 was a pretty straightforward (yes some of it entirely unrelated, were actually put in a separate container). If you did modules from the start “monoliths” could be broken down into ms if needed just by deploying them separately.

I will also add that libraries that operates at bytecode level (such as AspectJ) may be incompatible with newer JVM versions. This can be a problem since they are often used by higher level frameworks to do their "magic" (one example being Spring) [1]. The solution is that you have to update either the library (which may not be compatible with the framework using it), or the whole framework.

[1] https://stackoverflow.com/questions/23801950/spring-4-and-ja...

Yet, all that is besides the point: In essence, those reasons would apply to any installation you have once you run it long enough. I.e., those particular problems are not Java-specific, and in fact, I would even dare speculate that such issues are through the bench worse in any other language than Java.

ADDENDUM: Yes, C++ is technically even more backwards compatible - if your code base and all dependencies was/were 100% standards compliant (har har). But again, for me, the main point is that most newer languages first have to prove they can keep up to such levels of backwards compatibility (e.g., see the Python 3 fiasco...).

Maven is complicated but also very stable and powerful. It's no less arcane than webpack and if you're using any decent IDE all the available options will autocomplete. Fat jar deploys were always super simple and having a self-contained executable is even better.

Maven at its core is very simple. The lifecycle is well-documented and so is the dependency resolution.

Many coworkers I've worked with have called it complicated and then I find out they really haven't learned the (very simple) lifecycle and how build behavior gets attached, etc. This is all very simple but it is something to learn.

I don't know why this happens. I think programmers are so used to imperative (ant/Grunt/etc/etc) programming/building that it becomes confusing for them when they encounter a declarative system. And their brain revolts. Because they are like how do I just do a thing (i.e., copy some file somewhere, call a "build" method, etc, etc.)!? Instead of realizing the value of the declarative + idiomatic Tao and learning it...they say no, no gimme gimme let meee do it. Much like my two year old. And then I'm left fighting non-reproducible builds and getting their projects going in my IDE like it's somehow 2005 again. But Maven is great, declarative systems -- especially declarative build systems are the optimal way to do builds (in most cases).

>I don't know why this happens. I think programmers are so used to imperative (ant/Grunt/etc/etc) programming/building that it becomes confusing for them when they encounter a declarative system.

Because, after all is said and done, programming is about having your computer "do" something - whether it be to write some bytes to the disk or to send some bytes to the network.

It's just that sometimes there's an advantage to use an abstraction - such as say "SELECT * FROM TABLE WHERE ROW_ID =14" is an abstraction over something like "for (int i =0;i<table.size();i++) if(table.row[i].elem[1] == 14) ... ", but often you don't need such a complicated abstraction, you just "need something done" before (or after) building. Whether it be that you want to download an HTML file to package, or to move the resulting file to a certain directory, or to clean a certain directory, your build language shouldn't be that arcane that you have to create a "build.sh" to get things done.

— “SELECT...” is not an abstraction for “for...”, by the way. Abstractions are not for specific implementations. “SELECT...” is an abstraction for specifying Sets etc.

— Maven is simple, not arcane. I’ve produced countless “custom” builds with wild variations of need and never has Maven let me down. In some sense this is easy to prove (see maven-antrun-plugin); however, Maven’s core plugin/idioms supports 90+% of use cases I’ve seen over many many “weird” build requirements. To your example, “copying files” is fundamental; however you have to learn the idiomatic way to do it if you want to reap the benefits. Otherwise, just call out to maven-antrun- or similar. But then you’re chasing your tail.

I've never used Maven, only gradle.

The issue with convention over configuration is that you don't see how things should happen, because they're hidden behind the convention.

For example, what are the steps behind your Android build? Can you tell me exactly what steps gradle takes when you run gradlew assembleDebug?

So if for whatever reason you need to modify something, you're completely on your own.

Sure..

$ gradlew -m assembleDebug

Learn the tools you use..

> after all is said and done, programming is about having your computer "do" something - whether it be to write some bytes to the disk or to send some bytes to the network.

Not always. Often, particularly in scientific computing, you just want to ... compute ... a result. I mean sure, the computer needs to display the result to you, but the computation isn't about displaying it, it's about computing it. Just like adding up a bunch of numbers on a calculator isn't about getting the calculator to "do" anything.

> often you don't need such a complicated abstraction, you just "need something done" before (or after) building.

Abstractions should be simpler than the thing they abstract over, that's their whole point. Treating my computer's memory as a flat array of numbers is simpler than thinking about how much current is flowing through each RAM wire. "Compile all source files" is simpler than "execute javac Foo.java, then execute javac Bar.java, then..."

> Whether it be that you want to download an HTML file to package, or to move the resulting file to a certain directory, or to clean a certain directory, your build language shouldn't be that arcane that you have to create a "build.sh" to get things done.

You shouldn't need a build.sh, agreed, but nor should you need particular things to happen to particular directories. Maven has great support for things like "package my documentation in the standard way". It's only when people try to fight it about the low-level details that they really shouldn't be caring about that they run into trouble.

Could not agree more. Every time I have seen an implementation the imperative type (ant etc) it leads to different ways of doing the same things so over multiple projects things just gets really complicated and difficult to maintain.

I think it happens because maven has poor documentation, a ton of unexplained "convention over configuration", and very strong poorly explained opinions about how you must structure your project. Basically it's a ton of inflexible magic. Also, the attitude in the maven community that people that want to deviate from the god-given-way are two year old children.

The Maven manual is quite good, and there are plenty of books available for those that bother to sponsor development.

Maven's documentation is great, and the project structure is well explained. Inflexible yes, magic no.

This is basically the exact opposite of my experience with Maven. The documentation feels very clear and good to me and I've always found answers to my questions. I don't recall ever encountering "unexplained inflexible magic".

In around 2008 I co-wrote a set of maven javascript mojos (before NodeJS), incl QUnit test integration et all. I collaborated with another fellow on the other side of the world. Documentation was stellar. IIRC, to extend, even the upgrade from M2 to M3 didn't affect most community mojos.

Maven dependency resolution is not great, mind.

For example, if you have a multi-pom project with a parent pom (not unusual in a medium-sized codebase, never mind large), and you have unit tests in your child poms, they'll get executed with dependencies resolved locally for that child pom, and not with the global dependency resolution that satisfies all constraints that need satisfying at the parent level.

The upshot is that you easily end up running tests using different versions of dependencies than what you deploy with, misleading you into thinking things are working, and can end up with hilarious NoSuchMethodError at runtime.

The "solution" is to pin your versions using dependencyManagement, but that's no real solution at all, not least because it's neither automatic (though dependency convergance using Maven Enforcer helps, and I've developed some scripts that help further) nor is there an easy route forward when you want to bump versions safely.

Having the choice to pin versions separately per module is a desirable feature, especially for multi-module builds with different deploy artifacts. So this is no problem at all; deciding which versions to pin per artifact/module is the programming job — no tool can automagically decide this for you correctly.

I'd prefer the choice to specify versions in submodules, with the versions of dependencies chosen and pinned via the global resolution, producing a fixed set of dependencies in a file I can check in, like Gemfile.lock in the Ruby world.

> For example, if you have a multi-pom project with a parent pom (not unusual in a medium-sized codebase, never mind large), and you have unit tests in your child poms, they'll get executed with dependencies resolved locally for that child pom, and not with the global dependency resolution that satisfies all constraints that need satisfying at the parent level.

As it should, otherwise you'd get the even more hilarious situation where your tests pass when you run the single-module build but fail when you run the multi-module build.

> The "solution" is to pin your versions using dependencyManagement, but that's no real solution at all, not least because it's neither automatic (though dependency convergance using Maven Enforcer helps, and I've developed some scripts that help further) nor is there an easy route forward when you want to bump versions safely.

This is not a maven issue, it's a combination of Java's flat classpath and the reality of diamond dependencies on versioned libraries in any system. We could allow multiple versions of a transitive dependency on the classpath but then you get Rust's hilarious "expected Foo but was Foo" type errors. Java 9 modularisation should reduce the problem by allowing modules to have explicitly private dependencies, but the problem exists everywhere.

This is not a maven issue, it's a combination of Java's flat classpath and the reality of diamond dependencies on versioned libraries in any system

This isn't true; there are better solutions already existing. E.g. Ruby with the Gemfile.lock approach. I'd like to be able to do a two-step: do a global analysis of dependencies and pin the common versions for diamond situations, but not need to maintain or calculate those pinned versions manually. And I still get to use the pinned versions from the global resolution for executing tests etc. on submodules.

As it is, I've had to write a bunch of tools to rewrite the dependencyManagement as and when required. The main app I work on is linked into the Hadoop ecosystem, and that dependency set ends up being quite large.

Another issue with Maven is rebranding: when the groupId of an artifact changes, but the package and class names don't; see e.g. asm / asm vs org.ow2.asm / asm, or the whole codehaus debacle.

I have spent more than two weeks of my life updating, maintaining, fixing, researching and tooling Maven pom files, and it was almost all around deficiencies in dependency management.

Let's not get started on trying to get builds to work reliably offline, caching maven repositories, etc.

> This isn't true; there are better solutions already existing. E.g. Ruby with the Gemfile.lock approach. I'd like to be able to do a two-step: do a global analysis of dependencies and pin the common versions for diamond situations, but not need to maintain or calculate those pinned versions manually. And I still get to use the pinned versions from the global resolution for executing tests etc. on submodules.

I dislike this for the same reason as before: I find it really valuable that building a single module on its own behaves the exact same way as building that module as part of a multi-module project. If you want to ensure that the tests run against the same version as in the final product, I do that by making eviction an error.

> Another issue with Maven is rebranding: when the groupId of an artifact changes, but the package and class names don't; see e.g. asm / asm vs org.ow2.asm / asm, or the whole codehaus debacle.

Maven has better handling of this than most; it can at least warn/error when this has happened, and if you're using the shade plugin or similar it will warn or error when two jars contain the same classes. Yes it's a problem, but it's much more of a problem in other ecosystems.

> As it is, I've had to write a bunch of tools to rewrite the dependencyManagement as and when required. The main app I work on is linked into the Hadoop ecosystem, and that dependency set ends up being quite large.

There are standardized plugins for the common use cases e.g. "mvn versions:use-latest-releases". Most things that can be automated are. But since most of the library ecosystem predates version ranges and semVer, there simply isn't an automated way to know when using a newer version of a transitive dependency is safe or not.

Gulp is imperative, Grunt was designed to be used declarative.

> they really haven't learned the (very simple) lifecycle

Building is a simple concept: dependency DAG + inputs -> artifacts. The "->" here can involve arbitrary intermediate artifacts and steps.

Maven ignores this fundamental concept of building. Rather than treat interim dependencies as part of the DAG, there's a hard-coded recipe of lifecycle steps.

This is why I personally cringe at maven - it has nothing to do with the fact that it's declarative (virtually every build system is largely declarative). It has everything to do with hard-coding one particular set of build steps into a supposedly general build tool.

I was under the impression that the build chain in maven is pretty defined and not arbitrary. It performs the same thing over and over again, being highly reliable. It’s pretty extensible since you can tweak your own build steps if you want. And in the general case you don’t need to define a thing?

I used to use Maven but I've moved completely to Gradle.

With Maven, if you follow Maven's way of doing things, everything just works. But, if you need to do something different, or have some rare use case Maven's designers weren't focused on, you start struggling a lot to get Maven to do what you want.

Gradle is a lot more flexible and if you have some uncommon requirement you are far more likely to successfully implement it using Gradle than using Maven.

> But, if you need to do something different, or have some rare use case Maven's designers weren't focused on, you start struggling a lot to get Maven to do what you want.

You'll be fine as long as you realise the Maven-ey way of doing the thing is to write your own plugin.

But most of the time people just want their build to do something different for no real reason, IME.

One time I got frustrated enough with Maven not quite supporting what I wanted to do that I sat down and wrote a plugin that just did what I needed.

A short while later I was wondering why I'd never tried that before: Maven plugins are really quite simple to write.

I vividly remember starting my first java project a few years back and starting my first node project a year back, personally getting started with node was easily 5x more complicated with so many weird tooling before a first line of code is written.

Are you thinking of node or a web project? Node requires zero tooling and is distributed as a single executable ~10-20MB on all platforms + already comes with npm.

Making a web service via nodejs vs a web service using say dropwizad, all these web pack business is pretty complicated.

I’m still confused. Webpack is a frontend build tool and completely unnecessary for writing a web service.

Also, from the Dropwizard tutorial:

1) configure Maven 2) create a config class 3) write a mapping.yaml for “Jackson” 4) create an application class 5) create a representation class 6) create a resource class 7) register the resource 8) configure maven again (!) for building a .jar 9) finally run it.

With node you literally write 5 lines of code importing the http module and run `node server.js`. I can’t possibly imagine what steps could be more complicated than Dropwizard. I consider webpack overly complex myself, but it’s a completely self-inflicted option and not a standard for nodejs development at all. I’d be curious to know what docs you were trying to follow if you can recall.

Really?

1) Install node.

2) Write script. e.g.

  console.log('hello');

3) Run script:

  > node script.js

  hello

Java

1-10) Download Java *

11) Ensure JAVA_HOME is set right

12) Write java

  public class Hello {
    public static int main(String[] args) {
        System.out.println("hello");
    }
  }

13) Compile java

  > javac Hello.java

14) Run java

  > java Hello
  hello

* Yes, this is obviously facetious.

EDIT: Code formatting thanks to https://news.ycombinator.com/formatdoc

> other ecosystems including C++/Qt, Python, Ruby, Golang, and of course node/JS [...] Setting up a project is still a pain in the butt

I find this is not Java specific and many of those other technologies have similarly painful project config, especially as soon as you do something non-trivial.

> The Java world moves slowly.

"Vendoring" the stdlib, which essentially is what is happening here, alleviates that (at the cost of not sharing source, which is usually OK for the JVM in non-security contexts). As for work life vs home life, that is not very Java specific. Many companies hang back on old standards by choice.

  I find this is not Java specific and many of those other
  technologies have similarly painful project config,
  especially as soon as you do something non-trivial.

My experience with Java has indicated that the problem is actually in the opposite direction. I agree that all packaging systems suck for larger or unusual projects, but for small stuff there's a clear distinction - there is nothing in Java packaging that's trivial. Or you could see it as "nontrivial" being very different for different toolchains.

If I'm doing something that'll never exceed 1KLOC and doesn't depend on any exotic libraries, I can throw together a crate, module, bundle, package, etc in a matter of minutes and then forget about project configuration. Java... anything other than "local-machine CLI project with no dependencies and an IDE" will have you spending more time on config than code.

I find it's pretty straightforward using gradle (except that it doesn't build fat jars out of the box). Can you elaborate on what you're having trouble with?

I didn't try gradle and my experiences weren't incredibly recent (three-five years in most cases), so maybe that's what I was missing.

Dependencies and portability were by far the biggest issues. eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible. leiningen didn't have a single tutorial that I could find and I voodoo'd my way through a clojure tutorial before giving up. maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain. More recently, I could probably have gotten along with sbt if I'd had a week to play with it, but it also has the "no useful tutorials" problem and I was on a time limit.

Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths.

I'll look at gradle next time. There are situation where I could use a jar.

> eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible.

These things are oriented towards working with a dependency management/project management thing rather than manually specifying libraries. I'd really recommend maven, using the IDE's integration with it, particularly if you're getting started - Gradle can be more concise but it's definitely buggier and less well documented/supported.

> maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain

Dependencies should just work unless you were trying to do something weird like using jars from the local filesystem - don't do that (if you really must, install them into the local maven repository and use them from there: https://maven.apache.org/guides/mini/guide-3rd-party-jars-lo... ). You shouldn't need any incantations, just simple XML that should autocomplete in the IDE, or you can use a GUI rather than directly - e.g. in eclipse you just right click on the project -> maven -> add dependency, and search/select the library you want. Do you remember what problem you had more specifically?

> Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths.

SBT is awful throughout, but my experience is that Maven is much much better than anything in Python-land (no messing around and mode switching with virtualenv, no need to separately run pip, one consistent tool that everyone uses, one packaging format, one central repository, better integration of testing with the project), and directly comparable to Cargo.

If you've got a tiny project and are willing to use Kotlin on JRE 9, Kscript is a good option

I can start one of thousands of pre-configured projects instantly from maven central's archetype catalog (http://repo.maven.apache.org/maven2/archetype-catalog.xml). I don't even have to know what I'm doing to get a karaf-camel-amq-archetype or aws-lambda-s3-example project up in seconds. Java tooling is just so amazing.

How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it.

> How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it.

The book doesn't cover everything. That said, we currently don't have a built-in solution for this feature; we had one but it never hit stable. Since it didn't get accepted before the impl period late last year, the discussion was effectively on-hold; it can get started up again now that it's past the new year.

That said, many projects provide their own way to get started. Diesel's CLI has a "diesel setup" command to get going with it, for example. I'm not aware of one for Iron.

Thanks for the reply Steve. I enjoyed v1 and v2 of the book. I look forward to having a standardized way to do this in rust.

Iron and Diesel are pretty new, so they may not have very sophisticated templates yet. If you just mean setting up a rust project though it's as simple as 'cargo new --bin [project_name]'. I've found cargo to be a lot simpler to use than Gradle with the added bonus of not having to learn Groovy!

> It could reasonably be years before many shops transition to Java 9

Java 9 is short term support release, ending support with the release of Java 10 / Java 18.3 (March 2018). Next LTS JVM release is supposed to be 11 in 1.5 - 2 down the road.

A lof to large organizations will be holding back for the next LTS release before considering migration.

Setting up a Java/Kotlin/Groovy project takes two clicks these days: http://start.spring.io

And that is a simple template that just takes advantage of curated OSS ecosystem dependencies by the Spring team.

There’s really no magic, I find Maven or Gradle to be as opaque as say Gem bundles, Bower, or NPM and Grunt (Or whatever the new flavour du jour in Node land is). That is to say, the core concepts are all mostly similar but just slightly different enough to cause hair loss. And let’s not talk about Golang dependency managers...

Currently I'm doing C++ with Qt, sometimes C# (game dev under Windows), but was at Google just few months ago doing Java.

While Qt is great, we've been running into logistic problems - like we have plenty of tools that use it, and we are forced to place all the binaries into one folder ("bin"), and the Qt dlls there for legal reasons, license, but buying the license for static linking won't be a problem for us reallly. The real problem is that once we link our binaries statically, then our plugins that also use Qt won't work with them, unless we do some magic, and forward all QtXxx.dll end points to be from the main executable, or use more abstract interfaces - e.g. our plugins should not use Qt directly.

I likewise have used these. Qt (really C++) development in general suffers from annoyingly slow compile times in my experience. Also, once you go beyond anything trivial, .pro files become complicated as do build systems around them.

We don't use .pro files or QtCreator - it's Visual Studio + custom build rules. Still slow, and nasty with generation.

As build system, we used to have IncrediBuild, but since we are PS4 developers we get SN-DBS for free - http://www.snsys.com/products/SN-DBS.asp - it speeds up the build, but once the Qt moc/etc rules come in, the build needs to wait for these to be generated, and then proceeds.

There are ways to overcome this, and we are looking into improving this.

I've tried using .pro files, but first, I can't sell them to the rest of the engineers, as pretty much almost everyone knows Visual Studio, .sln/.vcxproj files. There are some ideas about alternative build systems, but not there yet. (at the end most of these just generate .sln/.vcxproj, like CMake, or premake, etc.).

My application is cross platform. So I use .pro files + qmake, then make/nmake. As I started needing to move files around in cross platform ways, I just maintain a Go script now that does the build. Tired of custom DSLs and having to dig deep into build-system-specific things (e.g. Groovy w/ Gradle and the confusion around what code runs when like defs vs tasks, doFirst, etc).

Try using "jom" as replacement for nmake - it's done by Qt themselves, and it's much better! - https://wiki.qt.io/Jom

I agree on the using some other language to do builds instead of using a complicated build process. Python is sufficient enough for me.

Why do you need to link statically?

> but buying the license for static linking won't be a problem for us reallly.

You can statically link with LGPL code, as long as you provide a means to relink (typically, shipping .o files if requested).

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

+1 for wanting to know what actually happens. I do not like the direction web dev is heading, with prepossessing, and transpiling a language that is already an embedded scripting language.

> 3. So much Java runs on the server side anyway, where executable size and entrypoint doesn't really matter that much.

I guess you could argue this might allow Java on the Desktop to be feasible again, but it might be too late.

When did it stop being feasible?

I surely get to use it more than Electron apps, thankfully.

So much misinfo/FUD in this post. I'll just respond to this one teachable point,

>You have some serious reading ahead of you if you want to set something up that isn't already templated somewhere for you.

Start with a maven project,

$cd /path/to/maven/project/

Create your archetype,

$mvn archetype:create-from-project

Install it in your local repo,

$cd target/generated-sources/archetype

$mvn install

$mvn archetype:crawl

Generate a new project from your new template,

mvn archetype:generate -DarchetypeCatalog=local

Oh wow! A complete maven project after only a few cryptic commands in weird generated subdirs and a -D switch! It's so simple and obvious it's almost criminal! I bet the OP is eating humble pie now!

I'm not feeding OP humble pie. I'm sharing information with people who are unfamiliar with Java, so they don't believe what professional Java developers can clearly see is obvious bait.

I'm glad freedomben likes nodejs, but he shouldn't talk dirty about Java while pretending to know something about Java. His one comment to this story dominated what could have been an otherwise interesting discussion about a new feature of Java 9. Sad.

> 3. So much Java runs on the server side anyway, where executable size and entrypoint doesn't really matter that much.

My read is that Java is doing this now because they ignored microservices and containerization at their own peril. 8 and 9 between them include a bunch of things to squeeze runtime and disk size to be comparable to other systems.

> ...squeeze runtime and disk size to be comparable to other systems.

Really? Most of the "microservice era" or "cloud native" or $timely_buzzword platforms are really big. Golang binaries for large services are bloody huge.

TL;dr don't assume other systems have small footprints until you deploy a Node.JS app and do "du -h node_modules/"

Microservices and containerization are the next cloud fad.

I am yet to do any enterprise Web project that isn't a classic application server.

Not everyone and his dog are jumping into it.

When I was coming up, I overheard a conversation amongst a bunch of greybeards about how these big computing organizational changes are not a fad, they're a cycle. Like the tides. Since I started working right at the cusp of a switchover I had one more opportunity to observe this behavior and test this theory than most people do, and it does appear to match reality.

People make monoliths for performance reasons and then can't maintain the monolith, so they go back to forced independence. Every company does this on a different cycle but the epicycles are the 'fads' you see, and it's been going on since at least the 70's.

Similarly and perhaps more forgivably, people organize a system (think, client-server, peer to peer) for reasons of the current laws of physics as they apply to clocks per second, storage space, and latency. Those inequalities shift with each new generation of hardware. So what was the right thing to do 15 years ago might be the right thing to do again next year. It's not that we've been wrong for 15 years, it's that we are wrong now. And will be wrong again in another half a dozen years. But we have to use the tools available to accomplish the goal now, and that means we have to adapt, repeatedly.

Is there any kind of cross platform development kit where for project set up it's not either magic or pain or both?

My only experience with Java was through BAZEL, outside of it I'm mostly Visual Studio guy with some Makefile knowledge.

With BAZEL things were working pretty smoothly, but I've never used maven, gradle, ant, etc. Really weird, because If I post that I have 3 years experience with Java and not knowing any of these tools...

What I'm trying to say is that with BAZEL this might be easier for cross platform development (not sure though)...

Do you mean some IDEs like IntelliJ or NetBeans?

The Red Language (which I just learned about yesterday) looks pretty good in that respect. One binary, no dependencies.

http://www.red-lang.org/p/about.html

I gather the GUI story on Linux isn't great at present, and there's no iOS support, but all of the other important bases seem to be covered.

I've tinkered with it a bit today, and so far it's as advertised.

> other important bases seem to be covered

Except accessibility for blind people (through screen readers), and probably people with other disabilities as well. I just tried the Red GUI with the NVDA screen reader on Windows, and it's mostly inaccessible.

BTW, this is a problem with nearly every GUI toolkit developed from the ground up (that is, from the host OS's low-level graphics primitives). The exceptions are mostly the big, "bloated" GUI toolkits, like those provided by the major operating systems, the major browser engines (and by extension Electron), Qt, JavaFX (though only on Windows and Mac), and maybe a few others.

Edit: SWT is one of the most accessible options for cross-platform desktop applications. That's mostly because SWT primarily uses the host platforms' native widgets. But it does have some custom controls, and for those, it implements the platform-specific accessibility APIs. I understand that a lot of people don't like the conventional desktop look and feel though.

I didn't understand the article, can someone explain what it means for java development, please??

Will we be able to create runtime-less executables that are fully dependency free? That would be awesome to write a bootloader in Kotlin or any other Java Synthax Substitute.

Whenever I start a new project I use http://start.spring.io/

Obviously it's Spring centric.

Good points. If you go back to java development and want to try a fringe build system, Kobalt is nice and straight-forward compared to maven/gradle. You configure the project in a kotlin file using a DSL. You may never need a plugin and the DSL + Kotlin give you a hybrid of Maven and Gradle.

http://beust.com/kobalt/home/index.html

> So much Java runs on the server side anyway, where executable size and entrypoint doesn't really matter that much.

This assumption is why developers are abandoning Java in troves with the serverless trend, where exe size and init time matter immensely.

And good riddance!

This feels like a weird time to say good riddance. Is this an anti-serverless post, or...?

Reply on news.ycombinator.com