I cannot keep my sanity when I use dynamic languages in fairly big projects. I just cannot organize my code and all the functionality good. So, I looked at the options at Java and most of them looked either very complicated(Spring) or insufficient. I am developing a very simple framework, insipred from Sparkjava and Play Framework: https://github.com/mustafaakin/WebOM It basically maps either HTTP requests or Websock…
I'm starting to put together my own Java web framework to make things easier to get started quickly and borrowing ( heavily) from other language frameworks. https://github.com/bluedevil2k/Jiffy
Java for Everything
111–120 of 344 posts
Re: Java for Everything
#112Having literally deciding to learn java last week for no particular purpose other than having enough understanding to be able to comprehend our software (which is written primarily in java) and prevent brain deterioration, I'm encouraged by the fact that the comments in this thread (so far) don't appear to be very negative (like when reading about php). While I did buy a book, I wonder if anyone has any suggestions o…
Re: Java for Everything
#113Earlier quoted context omitted.
While I do think Java is great I think that's an exaggeration, I'm sure there are quite a few deal-breakers for particular uses. Personally I've opted not to use Java before because it cannot compile to a self contained native binary.
You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.
gcj has been abandoned. It was last updated over 5 years ago. It's not clear to me why you would even mention it.
I'm a software developer that primarily uses and likes Java, and the lack of a good and free ahead-of-time compiler for Java that produces native binaries is what I miss most in the Java ecosystem.
Re: Java for Everything
#114It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.
Java's start up time makes it pretty crappy for command line utilities.
http://nicholaskariniemi.github.io/2014/02/11/jvm-slow-start...
The 'Hello' program there takes a little over 100 ms for me. I guess my computer is even less of a powerhouse than the author's.
FWIW, the Python equivalent takes about 30 ms on my machine. So, you pay maybe 70 ms to use Java. I don't think many users will notice an extra 70 ms on their command line.
Java's notoriously slow startup is really about the slow startup of software written in Java. Application servers are probably the worse offenders - how can it take a minute and a half to start a fancy webserver? What's it doing in there? They've got a lot better, though; the current generation of app servers start in one or two seconds. Not that anyone cool uses app servers any more anyway. Big bloated GUI apps also deserve some shame here (although i will forgive Eclipse, because i like my IDEs with some meat on them). Language platforms like Clojure and Groovy also manage to take their time, but then they're doing some pretty amazing stuff, i suppose.
Re: Java for Everything
#115It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.
IMO, being tethered to the JVM is both its greatest strength and its greatest weakness. The JVM really is a masterful piece of engineering, but it is optimized so heavily for the server that any use case that deviates requires huge hacks to get what you want. For example, running a JIT on Android was so sluggish that Android had to design an entirely new runtime(ART).
Re: Java for Everything
#116I was in full agreement aside from this. Unit tests are more than just a substitute for static typing.
Re: Java for Everything
#117This is exactly how I feel about Scala now. I really wanted to like Java because of the ecosystem and the JVM, but there ARE a few warts that you will face everywhere - verbosity is one, all the Spring stuff using annotations to wire up dependency injection and AOP and whatnot is another. Scala has the whole JVM ecosystem, static typing and forget about DI/AOP/OOP patterns. Feels like best of both worlds for me.
I find Java much more pleasant without Spring; I much prefer Jetty+Jersey+Guava+Guice. It sounds like that's pretty similar to how you're using Scala.
Re: Java for Everything
#118Re: Java for Everything
#119It's not so much that Java is great at everything. It's more like it doesn't suck at anything. Every other language has, somewhere, a deal-breaker for some particular use. I've not found one for Java. And Java's biggest downside, frankly, is that it hasn't attracted fresh young talent in a while, so it doesn't have really hot frameworks and libraries.
Java's start up time makes it pretty crappy for command line utilities.
Re: Java for Everything
#120Earlier quoted context omitted.
You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach.
You will be excited to learn about gcj, then. The Gnu Java compiler compiles to native code, but it's currently not maintained, so newer Java features are out of reach. gcj has been abandoned. It was last updated over 5 years ago. It's not clear to me why you would even mention it. I'm a software developer that primarily uses and likes Java, and the lack of a good and free ahead-of-time compiler for Java that produce…
There's also Excelsior, which is an AOT JVM, but it's for Windows only.
I agree that a really good AOT JVM would be very nice. It doesn't necessarily imply better performance however. I remember when GCJ compiled Eclipse for the first time, lots of people were surprised that it didn't magically fix every performance problems. GCJ engineers view was "HotSpot is an excellent compiler and it will take a lot of effort to beat it". When Sun Java became open source therefore, a lot of the incentive to develop GCJ disappeared. It was always primarily a licensing project not a performance project.