Java for beginners
zeroequalsfalse.press
zeroequalsfalse.press
https://projects.spring.io/spring-boot/
You can get a running webapp within minutes. The caution is, you would have limited information on what's going on in the background. Great for those who already know Spring and its inner workings because it's convenient - but could be detrimental on a beginner if you don't take the effort later to learn the inner workings.
Thanks.
https://www.udacity.com/course/java-programming-basics--ud28...
Java is permanently associated in my mind with hammer factories:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431....
Nowadays I still write Java, but it's much more pleasant, all deployed to the cloud, no messing around with application containers and all the Java EE stuff.
It's nice, it works, it's simple. Granted, I'm fortunate enough to not have to maintain legacy Java applications so my perspective has been skewed somewhat, but I think it's worth mentioning that "modern Java" has moved a long way from what it used to be.
Websphere was similarly popular because it could integrate with 100s of frameworks that developers/enterprises might be using in their applications.
So it still makes sense in same way when now people claim web apps/wrappers are solution to all client side software and if it feels bloated and slow, tough luck, "Why don't you upgrade to some over-spec'd machines?"
I was really green in enterprise software then, and Websphere's suggestion of useful clustering, configuration management, managed pooling, etc., seemed tantalizing. (Look how long it takes to start up--it must be doing useful and complicated stuff!) That said, it didn't take all that long for Tomcat, JBoss, and others to eat its lunch on projects not rolling along on enormous sunk costs into IBM tech.
I never actually dug into EJBs or wacky things like container-managed Javamail. Some colleagues did. They spent a lot of time struggling with the tooling.
And now I'm just remembering VisualAge for Java. /shudder/
EJB and XML may be little old and unfashionable but in its place Spring-Everything* is there. And now Spring annotation turdlets are sprinkled all over the newly fangled Cloud Microservices in Java.
But yeah, Java is great. Definitely seems underrated in the popularity department.
It just works, if a little unfortunately named, but you can get a nice little application up and running quite quickly.
I mean, if you're in that small scale range where you're running project off of a small server or VPS that may not have that much RAM to play with, the JVM I think starts to make less sense. You don't need the super-scaling performance of the JVM because you won’t have the load, and the RAM that would be spent on the JVM heap is better spent in that case on other things (e.g. database caching, if you are so small and cheap that your DB runs on the same machine as the http/app server).
So almost all "web" languages use garbage collection. This reason Java appears to use more ram is, paradoxically because it has a better garbage collector.
The best time to do garbage collection is never. Even if you do it concurrently it uses CPU time. Java is very good about avoiding collecting garbage until the heap is huge. Other languages (by default) use less ram because they run garbage collection a lot more often.
So why do they run GC so much more other than Java? Because their garbage collectors are slower and not as concurrent. Almost all garbage collectors pause execution and even the ones that don't still affect performance. You don't want pauses more than some tens of milliseconds really ever.
Garbage collection time depends on how much garbage you have, so languages with inferior collectors need to keep the heap small to avoid long collection times. Since Java's GC is so fast the heap can be allowed to build to many gigabytes before garbage collection times are an issue.
Turning down the heap size will make Java GC more often and behave more like other languages. Compared to dynamic languages Java itself is very memory efficient. It's just the longer GC interval that makes this appear otherwise.
The only popular languages that don't need a runtime installed are c/c++ and golang.
It may not be a fair rap, but you can see where it comes from if you imagine that lots of people had their introduction to webapps in the form of LAMP shared hosting stacks.
In my brief recent return to Java, it still doesn't seem to reach out to the programmer to make the common case easy.
You mean like using go generate instead of proper generics?
IDEA is phenomenal. Netbeans is just OK, and Eclipse was awful all the times I tried it. Bloated UI, slow startup, and difficult to configure. Maybe things have changed since I've used it, but at the time, it was agonizing.
Configuration is easy; there are a zillion options under preferences but the search filter makes it easy to find what you need.
Startup times are irrelevant. Start the IDE once when you boot the OS and leave it running. It consumes minimal system resources just sitting there until you need it.
The only part of writing/maintaining code that I've found easier/more pleasant with dynamically typed languages is writing unit tests (due to the fact that mocking an object is as simple as just declaring a hash literal or JSON object). On the other hand, I find that I need to write extra unit tests to verify integrity that would be be verified at compile time in a strongly typed language like Java.
I would strongly recommend people check out DropWizard. It's an opinionated framework for writing Java servers that comes with a handpicked stack. It has many of the convention driven advantages of e.g. Rails but fundamentally you're still writing code in Java (or another JVM language like Kotlin).
This is so true and I'm surprised I don't see it mentioned more often.
Sure, mocking stuff is way easier in JavaScript, but you end up writing tons of tests to prevent the kind of regressions a smart IDE would be screaming about in a strongly typed language.
This is normal for any mature, widely used technology - Rails comes to mind as a smaller variant of the same problem. It's a lot easier to try out go or node - there's less stuff.
Im convinced that most of the people who dislike Java are either riding the hype train or inexperienced with the pitfalls of various languages.
The whole startup culture is biased against Java which is ironic because many tech titans use it as their main language.
For example:
https://www.zeroequalsfalse.press/2017/06/22/java/output.png
- The author and date are redundant, these are typically stored in source control
- The program itself should already be a class, specifying a containing class and function shouldn't be necessary.
- Public (or private) should be default.
- Make returning void a default, and stop asking developers to unnecessarily define it.
- 'System' is a vague word with many possibilities. It can man: OS kernel, services, OS, VM, stdlib, and many others.
The entire example except 'print("hello")' is wasted tokens and noise.
Package private is a reasonable choice for the default access modifier. Changing the default to be public or private wouldn't improve the language.
Ack, but it's a strange culture that does so.
So you can omit 'public' or 'private' as keywords and the function / method will be package-private?
However, I do think a lot of the library ecosystem that goes with Java it pretty poor, and I don't think I could ever work with Spring again.
This gist of Java frameworks for me is that they miss the essential problems and important uses and instead construct a massive tower of nonsense around the trivialities.
(I am, however, quite happy with Guava and Joda Time, and if I thought that dependency injection frameworks were useful then Guice is certainly superior to Spring.)
So here's my anecdote illustrating the dark side of Java.
Once upon a time, I needed to parse a CSV with a header row. The project I was working in used Spring, so I decided to try the Spring library. Configuring it to fetch the bean, put it in the right place, and set the header row switch to true took slightly more lines of XML than the lines of code you'd need to write a CSV parser from scratch, but hey at least I didn't need to think about quoting.
After a year or so, we are updating to a newer version of Spring. They have removed the header-row switch from their CSV parser, and replaced it with some sort of general parser extension abstraction. To parse a CSV with a header, I now have to write a class implementing their parser interface, register it with Spring, then write another 10 lines or so of hideous XML to slot it into the right place.
Just...what the hell?
Bean Validation can piss off too.
Sure, you want to provide a bunch of different readers, and let people put them together however you want.
But compare the example there of using a BufferedReader in a loop to read in a file, and compare to the equivalent in C# - File.ReadLines (which gives you an IEnumerable<string>) or even File.ReadAllLines (which gives you a string[]). 99% of the time that's all you want, and yet Java makes you do the work yourself rather than just giving you a utility method.
I get your sentiment though.
[1]: https://docs.oracle.com/javase/7/docs/api/java/nio/file/File... [2]: https://docs.oracle.com/javase/8/docs/api/java/nio/file/File...
I'd change that to, "commenting code that is self-explanatory is so often overused when developing software and it is a damn shame"
In the very same article, there's a function with the following JavaDoc description "A simple add implementation that performs addition on two integer values". Nothing I can't get from actually "knowing how to read code".
Programing syntax isn't usually the difficult part once you know two or three languages.
Is that really true though? Anecdotally it seems lots of big firms are using Java8 even more often, as sidetracks to Go/Scala/C++* seem to be coming back.
I really like Java actually, although we do make use of things like Lombok pretty heavily to reduce the boilerplate, enforce using inheritance very sparsely, and use immutable value types wherever possible (although sadly this is the part that gets ignored most often) - doing those things greatly improves the experience of using Java.
http://robovm.mobidevelop.com/
https://software.intel.com/en-us/multi-os-engine
> Is that really true though?
one data point: yes