471–478 of 478 posts
Earlier quoted context omitted.
If it lives up to claims surely it’s a paid for add on?
It works really great with heaps >100GB and is included in the openjdk since 11. Note, that only linux is supported, I think
Earlier quoted context omitted.
So far I did not find anything comparable to replace Java for website server language. Go is a terrible extremely verbose language without vital features. JavaScript on Node is limited by single-thread and JavaScript itself is a terrible language (along with other dynamic languages like PHP, Python, Perl, Ruby). Rust is awesome, but I don't think that it'll be ever usable for mediocre developers, therefore it can't b…
Bit of a Go fan here so just wondered if you'd qualify what you mean by: > without vital features
Earlier quoted context omitted.
Actually they just said that Java's server-side stack is overengineered, and that Spring/Spring Boot hides that complexity. I think that is mostly true.
"Spring/Spring Boot hides that complexity" Until it doesn't, then everything goes to Hell very quickly. Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. Program logic is defined in anything and everything, except ac…
I see a comment like this every week on HN and I've been meaning to write a blogpost or two to address this.
Yes, as you mentioned there is a myriad of ways to configure a Spring(Boot) application, and I think that is one of things that make it such a powerful framework or platform to build a service on. To address a few of your points:
* beans defined in XML : we don't do that anymore since annotations got introduced. I haven't written a beans.xml file in years.
* Program logic is exactly where you expect it: in the Java code. All the property files and annotations are used for configuration to allow for different environments. This setup allows us to run the exact same binary jar or docker image built from CI to run in CI, in dev, in staging and in multiple different production environments.
* configuration settings and property files are the same thing as the configuration values go into property files, you can have multiple property files to group configuration logically by their purpose, and if needed duplicate each property file per environment to group those together. I know my database config for the staging environment is in database-staging.properties. If that is not enough you can easily override any of the values with environment variables
* Debugging : another point where Java gets huge flak here on HN is huge stack traces, well I think those are actually helpful in figuring out exactly what is running and giving you trouble in a specific environment. And because of the separation of configuration from code mentioned above it is trivial to setup a testcase with the exact same configuration that you are having trouble with and use a debugger on that testcase to inspect and debug.
* Simplicity and composability : While the framework can look complex if you don't understand the configuration system, it is actually there to facilitate composability. See my point about running the same binary in all environments. The big idea is that you put all code in the same repo and then compose and configure your application at runtime with the configuration system.
Earlier quoted context omitted.
"Spring/Spring Boot hides that complexity" Until it doesn't, then everything goes to Hell very quickly. Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. Program logic is defined in anything and everything, except ac…
> Spring is close to impossible to debug, because everything is driven by annotations, configuration settings, property files, beans defined in XML, default values, or code that runs because you added a dependency even though you never explicitly call it. I see a comment like this every week on HN and I've been meaning to write a blogpost or two to address this. Yes, as you mentioned there is a myriad of ways to conf…
> beans defined in XML : we don't do that anymore But you still can do that! Also you still can do DI with Autowired private fields instead of injecting via constructors. You can also create beans based on properties. You can also create beans automatically via a included JAR on your class path. On Spring Boot you can also have beans created based based on some conditional annotation. And now there's yet another new DSL [1] to create your beans programatically on startup time. Tracking down and debugging what's loaded in Spring is super hard compared to Guice for example.
Configuration is another piece of software that I have a really hard time to think why they do that. You can configure via a YAML file, AND via a properties file, AND overriding via environment variables, AND also with a configuration server that store your properties on a separated server, and they are all mixed together in a weird single configuration entry for the specific environment that you have. Probably this made sense some 10 years ago when we loved J2EE but why support this kind of madness nowadays?
What I feel Spring is missing so much is forgetting about all the past and where the framework came from, start from scratch with simple premises around reactor-netty [2], only supporting the functional DSL, no crazy class path scanning, no crazy configuration loading, just a simple DI framework with some batteries included.
[1] https://spring.io/blog/2017/08/01/spring-framework-5-kotlin-... [2] https://github.com/reactor/reactor-netty
Are they ever going to release value types?
I share your frustration but this new GC should drastically reduce the issues with creating tons of garbage. There's still the infamous "allocation wall" but value types wouldn't solve that either. But they would make it a lot better
For example: https://rcoh.me/posts/cache-oblivious-datastructures/
Earlier quoted context omitted.
Is newer Android fully JVM-8 compatible? It'd be great to be able to start using Scala 2.12 even if it means I have to restrict to new devices only.
Not really, a lot of desugering still takes place into DEX bytecodes. Stuff like lambdas take extra memory, because they convert into anonymous innerclasses instead of invokedynamic.
Earlier quoted context omitted.
What was your problem specifically ? For me these two worked great together actually. I really loved Spring. Maybe the problem has some overlooked fix that I can help with ?
Nothing in particular just lots of seemingly random issues trying and failing to get them working correctly, likely due to my lack of knowledge but every time I try to better learn them my brain just can't handle it. I don't know what it is. I think part of it is my auto-cringe when I see XML nowadays.
Earlier quoted context omitted.
does it create a native executable?
It builds a directory of files which contains a .bat to launch the bundle.
The major point of JavaFX is cross platform development. Please offer a cross-platform jpackager, and we'll be happy.