This gets a thumps-up from me. I love REPLs in general, and I think it's pretty sweet that Java is getting JShell. It's great for beginners, but also for any level for experimenting with ideas and APIs.
You're confusing packages with classes. Arguably, the same number of package dependencies in Java could mean even more abstraction that's inherited for each.
I'm fairly impressed with how Java has maintained relevance and steadily improved over the years. Java 8 was huge in tackling the Functional programming front. With REPL and more functional improvements in Java 9 its starting to feel fresh again. Go & Swift are great efforts and I hope they gain a larger community but JVM is here to stay and it's great that they're improving it while so many other languages have fizzled out over the years.
Definitely. While at times it feels like the Java Community Process moves at a snails pace, the maintainers of Java have done an incredibly good job modernizing Java and addressing its flaws over the years, while all the time maintaining backwards compatibility and, most importantly, keeping a single unified developer community.
When you look at how dominant languages like Perl and even Python have stumbled between version changes, it underscores how much of an accomplishment this really is.
It seems like the JVM is here to stay in the same way that COBOL is here to stay. It has become a server-specialized system with a level of overhead that kills it in resource constrained environments. There is room for improvement, no doubt, but it's pretty hard to beat the resource demands of AOT compiled code with a good optimizer and potential PGO.
Go, Swift, Vala, Nim, and Rust are just the start of a trend...it seems most new languages are eschewing the VM model. And many existing VM/JIT languages are moving there: Dart, Julia, Scala, and even the .NET languages are all moving towards AOT capabilities.
Java is also AOT compiled and is becoming the favourite language besides C on many embedded platforms.
EDIT: To expand to that remark, although Sun was religiously against AOT, the majority of commercial JDK vendors have always supported AOT compilation to native code, specially the ones in the embedded space.
Also, for how cool all those languages are, there are lots of domains and OSes where Java code lives (AOT or JIT compiled), that they have yet to create backends for.
Examples, embedded controllers on factory plants, Cisco phones, Ricoh printers, Gemalto monitoring devices, Blu-Ray players, car infotainment systems, some GPS devices, military weapon control systems, shopping terminals, Android's fork,...
I was more claiming that the JVM is going obsolete, not Java. The whole idea behind the JVM is platform abstraction...and it worked perfectly fine insofar as the platform being abstracted had a CPU, at least X memory, a disk drive, and at least a basic OS. Which was fine for a while, but now we're seeing an explosion of different platforms with wildly different capabilities, and the JVM is just not up to the task. That isn't to say that Java isn't, but it does mean that you need specialty compilers, libraries, tools, and infrastructure for specialty targets.
Well, actually what we are seeing with the CLR, LLVM, ART is an increase of adapting the mainframe model of JIT/AOT compilation with some form of bytecode as distribution model.
In that regard, what JVM is missing are new ways to adapt to said hardware.
Interesting enough, Java is ahead of Go, Swift, Vala, Nim, and Rust in supporting GPUs, for example.
> To avoid redundant code and more re-usability, Oracle Corp is going to introduce private methods in Java 9 Interfaces. From Java 9 onwards, you can write private and private static methods too in an interface using ‘private’ keyword.
To me this seems sane only to be used with the `default` keyword. Am I right, or did I miss something?
The last time I used Java the Optional waas mostly usable, but had some rought edges, and I saw that all my painful usecases were waiting to be released in Java 9. When I last checked unfortunately the monadic types were still not sharing an interface for common operations (Optional and Stream), not even in Java9.
Overall: finally it is here! I miss some parts now from the .Net Core world.
If you can define private methods on an interface then you can refactor common code out of default methods on that interface without exposing it to any other class.
"java" and "cool" in the same sentence doesn't compute for me. I die a little inside every time I'm forced to launch eclipse and work with The Old Stuff.
Actually after working with java from 97-07, I was so sick of it I started the process of changing careers and study medicine. Just imagine: solve people, not code!
Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.
I hear people these days do write fun, lightweight microservices that launches in seconds in java, but I'm scarred for life. Never again. Life is too short and there are tons of fun programming languages that are commercially viable.
(I never started medicine, programming is amazingly creative, just not java)
I agree. I dipped both feet in those and other Java technologies and I really had trouble enjoying programming. It always felt like I was fighting with configuration, JAR versions, and other useless complexity. I don't even want to think about all the dozens and dozens of hours I wasted fixing Maven problems.
Now that functional languages are showing how easy it is to handle the increasing number of CPU cores, Java just looks like a dead end... except maybe for use as a Scala VM.
But if you're going to move away from Java, it's also good to move away from the problems of the JVM. Personally, I've gone with Erlang/Elixir on the BEAM, giving me access to the brilliance that is the OTP.
I was in a similar place where Java (and the other languages I knew at the time) had made programming stop being fun. I started to wonder if I needed a new career. But instead I learned Python and it made programming fun again. That was 8 years ago and it's still fun.
I'm the exact opposite. I hate writing Python. The language is far too loosey goosey to be productive in beyond small little tools. I feel like I am constantly fighting the packaging system, tool chain, ecosystem and documentation.
Java and more recently Kotlin keep me sane and make developing a pleasure. The ecosystem is remarkably consistent. I'm working on a Python code base right now and everyday feels like being punched in the kidney repeatedly on the hour.
> Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.
One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things?
> I die a little inside every time I'm forced to launch eclipse
> One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things?
It's hard to pinpoint one single thing that is the problem, but I suppose I can summarise it with that I don't think java is especially productive.
The language is rather verbose in modern terms (compare it to something with type inference like swift or rust).
The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time.
Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")).
Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc).
The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security).
It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however).
Things like ORMs (Hibernate and EJB) meant most people just forgot how RDBMs work and threw crazy hardware at the persistence layer to compensate for lousy performance (ORMs are typically fine, users not understanding how they work are the problem).
> The language is rather verbose in modern terms (compare it to something with type inference like swift or rust).
Maybe if you never have to work with anyone else, or maintain your code. Static typing is a plus, not a minus. Right now I'm working in a legacy codebase where everything is passed as Object or String within the main logic code, and let me tell you it's hell trying to figure out something as basic as what type of object you're working with.
> The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time.
Startup time for thin servers like Jetty is virtually zero. The fatter servers definitely do take more time to start up, but they also tend to be used with complex applications that have more stuff to configure, so that goes hand in hand.
For a point of reference here, I'm at about ten seconds from startup to page load with a 110 MB application that loads all kinds of redundant and useless code (which is why you let Maven do its thing instead of using fat jars everywhere).
If you're properly configured, though, you can do "code hot-swapping" (call 1-800-TOMCAT for sexxxy singletons in your area!), which will just inject a new function body into the server, so you can avoid having to re-deploy the whole application over a single changed line.
> Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")).
If you need a little more flexibility than just "this object but serialized as JSON", you can control the binding with annotations or XML.
> Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc).
So you don't like writing it yourself (SAX parsers are verbose but fast and powerful), and you don't like the tradeoffs of letting tools do it for you, ok then...
JAXB isn't really as bad as you're making it sound though. And the rule of thumb is that virtually any awkward block of code can be stuck behind a convenient helper method and only touched directly if there is a very compelling reason.
> The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security).
Sure, object references can be null. Get over it, that's like CS 101 stuff right there. What do you think happens if you use an undefined variable in Python or Javascript?
If you really want to be sure that an object isn't null, just use "assert myObj != null;".
Again, static typing actually is a huge plus when you're looking through unfamiliar code and trying to figure out what it does. "What type of objects am I working with" is a fundamental question that you always need to know.
> It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however).
> Things like ORMs (Hibernate and EJB) meant most people j...
> Sure, object references can be null. Get over it, that's like CS 101 stuff right there. What do you think happens if you use an undefined variable in Python or Javascript?
I think you missed the part where he's comparing against statically typed languages like Rust and Swift. He's not arguing against static typing. He's arguing that Java is both more verbose and less type-safe than languages like Rust and Swift, which both prevent null, and have type inference.
> Get over it
Why get over it when you can just use a language that doesn't let null leak into every reference?
> Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.
Imagine the fun of doing that in C and C++ before Java was known to the world.
It used to be called COM, CORBA, OLE 2.0, DCOM, SOM.
Any language in a EE environment suffers from space architects.
> Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.
Most of those things aren't even Java-specific.
IOC is just a design pattern that asks you to consider whether you should be writing a web server or, say, a request controller that runs on a web server. Since the web server invokes your controller method when it gets a request, we say "control is inverted", because the server is actually driving your application. You are surely doing something similar in any other language you choose, whether or not they tell you it's IOC.
As a whole - from the user (programmer) perspective, Java EE is in fact mostly just a collection of such IOC patterns that have been provided for you to "fill out". This is a servlet template, this is a filter template, etc...
XML is XML, nobody argues that it's not verbose, but it's not difficult to write. With a DTD file specified, an intelligent editor like IntelliJ will suggest element/attribute options for you, which is about as easy as it can get. It's certainly better than a properties file where you don't get any auto-suggestions, but if you want something a little more imperative you can also configure most components programmatically now (i.e. you get a configuration object that you can set settings on, then you call "build()"). Spring and Hibernate both support it, at a minimum.
Glassfish is just an application server. I don't use it, Tomcat is more than enough for most web apps and in fact you can usually get away with a "thin" server like Jetty in most cases.
Spring is such a broad topic that it's almost pointless to talk about. Are we talking about just Spring? Spring MVC? Spring Test? Spring Boot? Spring Security? Each of those solves something different, and frankly each of those also happens to do it much more cleanly and efficiently than anything that came before. Having worked with Struts and directly with low-level Servlets, Spring MVC is a breath of fresh air.
The basic Spring is just a dependency injection system. For most people, that boils down to a nice way to auto-build your ORM instance and inject it into your controllers. You can take it or leave it, it's about a page of code to replicate it in most applications, but it gets increasingly useful in more complex applications and with more complex use-cases because it lets you side-step the question of what environment you're running under in the code itself, and push that into configuration. You can run integration tests against a specific testing database, a SQLite you set up just for the test, etc, and the application doesn't need to know.
Maven is actually the most fantastic thing about the entire Java language. It's a universal project file format that is understood by every single IDE on the market, no more messing around with putting libs in classpath. It's also one of the few 100% reliable packaging systems that I've ever worked with, it will Just Work, 100% of the time, no matter your environment. I've spent so much time fighting pip and bundler over system libraries that need to be installed, 64-vs-32-bit problems, not liking cmd or Cygwin environments, etc. The only complaint I can make about Maven is that you can't just pass it a directory of libs and say "include these"... but it's very obvious why it doesn't do that, it kind of destroys the purpose of explicitly specifying your dependencies. The solution of declaring a local repository inside your repo is less than obvious, but it works. And again, on the whole it's much better than Ant. I would actually rather use a makefile than use Ant.
In general you're right that there's certainly tools that will let you overengineer things if you try. Who could argue with that in a world where AbstractSingletonProxyFactoryBean exists? A lot ...
Compact Strings is listed as a "miscellaneous" feature but that is the most exciting feature as far as I am concerned. IIRC based on looking at a variety of heap dumps they found that decreases the average size by like 10%.
Because it's the most used language in enterprise software.
It's reliable, rather easy to learn, and quite productive. It's not particularly fun, but it works and the tooling is pretty great.
If you already have a big Java code base and/or your employer forces you, or there's some killer bit of code that is absolutely crucial to you and it's more effective/efficient to choose Java to be able to use it than to find an alternative or rewrite it in another language.
> from good to amazing with Java including Scala, Clojure, JRuby, Groovy, and Kotlin
After writing "good to amazing", you put an ordered list which many readers will subliminally rank in the order you provided, with the "amazing" languages on the right. I've tried 4 of those 6 languages, and would rank them in a different order.
> Ecosystem has several good other languages that interop from good to amazing
The ecosystem also has several other languages that interop from bad to amazing, just like other ecosystems.
How is this different from any other language? Let's face it, every language is just a Taco Bell menu item (1), choosing from them same dozen or so ingredients.
Java dev here, excluding legacy code, very little reason.
I find clojure a significantly better language, and theres always kotlin / scala if static typing is your thang.
People tend to conflate the not-so-nice java language with the good parts (libraries and JVM). The performance of the JVM and the same massive ecosystem of existing libraries are available in clojure, scala and kotlin.
Performance wise I've never encountered a problem:
- protocols have the same performance as interfaces but with significantly more power (solving the expression problem by default prevents so many headaches when you have to add more functionality later)
- loops and other binding constructs can have type hints to allow java-speed numerical operations
- immutability by default does have a cost in memory and cpu, but the ease and safety of concurrency it has enabled in my codebases more than makes up for it, e.g. "oh i've got a large (>100000 elements) of data being processed here in various ways (map, filter etc), lets parallelise that and give it a thread pool"
I feel that if I were truly performance constrained in clojure its likely I would have performance troubles in java, the difference is just not big enough.
BUT if such a situation came up, theres nothing to stop me coding up my super duper ultra performance needed code in java and just calling it from my clojure codebase. Interop is very nice.
YMMV but its never been an issue in my day to day work (mainly involves analytics, visualisation, web services)
My experience with kotlin so far has been great. I've used it in personal projects, and am in the process of converting some microservices at work to it from java (the interop is seamless, so I'm able to do it incrementally as opposed to a full rewrite). People ask me what the difference is between kotlin and java, and I typically reply with "it's java, minus all the bad stuff". Variable types are inferred, map/reduce/filter are builtins and don't require going through a Stream, there's no need for Guava anymore since listOf() and mapOf() are builtin, boilerplate-reducers like data classes continue to speak to the whole "it's pretty much java, but how you _want_ to write it" mantra. It nails all of the little things that java has just missed, like in an if-block after checking a variables instanceof, you don't need to explicitly cast it to that type. There are tons of simple things like this that just come for free, and when you go back to java it's amazing how much extra, pointless boilerplate you need to write. I personally don't see any reason for me to ever write java again.
Mixed reasons Java/JVM environment (applies to Clojure, Scala, Groovy, etc):
1. Dependency management done right. Maven and Grade simply blast away most other dependency management systems. So yes, the code may be longer to write than other languages, but it's very easy to reuse code that's already written (by you and others)
2. Plenty of high quality third party libraries. Thank the enterprise, thank Android, thank whover you like: they just exist.
3. Stable APIs, libraries, and language. There have been very few occasions where backwards compatibility was broken in Java, and those were mostly very complex edge cases that occurred quite rarely. Nothing like py2->py3 btw. Sometimes slow is not so bad; it means you don't need to fix your code every 3 months because something changed upstream.
4. API/Interface first. Java encourages modularity and composition; J2EE may be a monster since it's comprised of dozens of interfaces, but it actually makes it very, very easy to "swap out" a single component with your own implementation without needing to rewrite/fork a whole library or framework. The way most things in Java work and interact are perfectly documented and standardized; combining even tens of different libraries is easy, you don't risk that each author has a different opinion on 'the right way to do it' that makes it not compatibile with the others.
5. Excellent tooling. Java IDEs are really advanced and can perform error-free refactoring and other operations on large projects.
6. Works on many platforms, in quite an expected and homogeneous way.
It's annoying that every time I see a reference to Jigsaw it is only in the most abstract terms. Never an example or anything concrete enough to explain what is involved. Couldn't they just say: "Jigsaw introduces a source level module construct.."
Looking how well it does support Java 6, 7 and 8, probably never.
- Java 6 and 7, not all of the APIs are supported
- Java 8, on top of not supporting all of the APIs, it doesn't support the new bytecodes and 100% of the language changes. As Android team puts it at Google IO, "tell us which features you care about", apparently 100% isn't a goal.
Also the new compiler toolchain required for Java 8 support, Jake and Jill, still doesn't work properly.
Also there are several issues, where Android has implementation bugs versus what Java libraries actually do, e.g. String::split.
In a 5 years time, more or less when Java 10, hopefully gets released, the fun of writing portable Java code between Android Java and standard Java will be even better.
I used to be a "Java hater" when I didn't understand the real purpose of the language or didn't even write in it. I was pretty young and it was cool to hate it.
but nowadays, I think having a common runtime plus a language that can exploit that is quite nice. having written some java lately, it was a refreshing break from the brutalism of C.
looking forward to whatever they bring to the table!
EDIT: java without any IDEs is also very usable. my workflow from small C projects didn't change. I don't bother with Eclipse, I just do all my work in my terminal.
Add bsh.jar and a little glue code and presto you have a shell into your application.
There was a Java-based editor, jEdit, which integrated with Beanshell. I could do search-and-replace with replacement programmed in Beanshell. Aah, these were good times.
74 comments
[ 2.5 ms ] story [ 155 ms ] threadLook it up, its nice.
Python has a pretty tedious class definition syntax too, and nobody ever accused Python of having a bad REPL!
Every time I hit an IntStream/FloatStream it just feels like a jarring experience. We shouldn't need functions like mapToInt()/mapToLong()/etc.
When you look at how dominant languages like Perl and even Python have stumbled between version changes, it underscores how much of an accomplishment this really is.
Go, Swift, Vala, Nim, and Rust are just the start of a trend...it seems most new languages are eschewing the VM model. And many existing VM/JIT languages are moving there: Dart, Julia, Scala, and even the .NET languages are all moving towards AOT capabilities.
EDIT: To expand to that remark, although Sun was religiously against AOT, the majority of commercial JDK vendors have always supported AOT compilation to native code, specially the ones in the embedded space.
Also, for how cool all those languages are, there are lots of domains and OSes where Java code lives (AOT or JIT compiled), that they have yet to create backends for.
Examples, embedded controllers on factory plants, Cisco phones, Ricoh printers, Gemalto monitoring devices, Blu-Ray players, car infotainment systems, some GPS devices, military weapon control systems, shopping terminals, Android's fork,...
https://en.wikipedia.org/wiki/List_of_Java_virtual_machines
It is going to take a while to erase Java from the industry.
In that regard, what JVM is missing are new ways to adapt to said hardware.
Interesting enough, Java is ahead of Go, Swift, Vala, Nim, and Rust in supporting GPUs, for example.
Like what? Even $40 dev boards these days have 8 core processors and 2GB+ of RAM.
Though I think JVM-as-a-spec is still incredibly powerful, even on Android. I can write Kotlin apps, Groovy apps, Scala apps…
http://www.oracle.com/technetwork/java/embedded/embedded-se/...
http://m.ibm.com/http/www-01.ibm.com/software/wireless/wece/...
http://www.ptc.com/developer-tools/perc
There are a few more.
All of them without the hungry requirements of Android and compliant with Java TM license.
Of course Java won't be able to run on Arduino and similar tiny controllers.
There are tons of comercial applications running embedded Java in hardware people might not be aware of.
Google's arguments regarding why they had to fork Java are just smoke and mirrors, only believed by those that only ever used the OpenJDK.
To me this seems sane only to be used with the `default` keyword. Am I right, or did I miss something?
The last time I used Java the Optional waas mostly usable, but had some rought edges, and I saw that all my painful usecases were waiting to be released in Java 9. When I last checked unfortunately the monadic types were still not sharing an interface for common operations (Optional and Stream), not even in Java9.
Overall: finally it is here! I miss some parts now from the .Net Core world.
Actually after working with java from 97-07, I was so sick of it I started the process of changing careers and study medicine. Just imagine: solve people, not code!
Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.
I hear people these days do write fun, lightweight microservices that launches in seconds in java, but I'm scarred for life. Never again. Life is too short and there are tons of fun programming languages that are commercially viable.
(I never started medicine, programming is amazingly creative, just not java)
Now that functional languages are showing how easy it is to handle the increasing number of CPU cores, Java just looks like a dead end... except maybe for use as a Scala VM.
But if you're going to move away from Java, it's also good to move away from the problems of the JVM. Personally, I've gone with Erlang/Elixir on the BEAM, giving me access to the brilliance that is the OTP.
Java and more recently Kotlin keep me sane and make developing a pleasure. The ecosystem is remarkably consistent. I'm working on a Python code base right now and everyday feels like being punched in the kidney repeatedly on the hour.
One of the most popular frameworks - Spring Boot - includes many of these now. It's fairly light, contained, works well in Docker. Maven is pretty straightforward for simple things, IOC is optional. I haven't exercised it heavily though, but what's wrong with those things?
> I die a little inside every time I'm forced to launch eclipse
Intellij's your healing potion then.
It's hard to pinpoint one single thing that is the problem, but I suppose I can summarise it with that I don't think java is especially productive.
The language is rather verbose in modern terms (compare it to something with type inference like swift or rust).
The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time.
Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")).
Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc).
The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security).
It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however).
Things like ORMs (Hibernate and EJB) meant most people just forgot how RDBMs work and threw crazy hardware at the persistence layer to compensate for lousy performance (ORMs are typically fine, users not understanding how they work are the problem).
It's owned by Oracle.
I could probably go on, but it's bed time.
Maybe if you never have to work with anyone else, or maintain your code. Static typing is a plus, not a minus. Right now I'm working in a legacy codebase where everything is passed as Object or String within the main logic code, and let me tell you it's hell trying to figure out something as basic as what type of object you're working with.
> The startup time of a spring-driven project used to take an age (used to be XML-parsing, then annotations), especially if housed in an app-server like jboss or glassfish, but also tomcat, jetty (compare it to how quickly an express-app in nodejs starts). This in turn affects development time.
Startup time for thin servers like Jetty is virtually zero. The fatter servers definitely do take more time to start up, but they also tend to be used with complex applications that have more stuff to configure, so that goes hand in hand.
For a point of reference here, I'm at about ten seconds from startup to page load with a 110 MB application that loads all kinds of redundant and useless code (which is why you let Maven do its thing instead of using fat jars everywhere).
If you're properly configured, though, you can do "code hot-swapping" (call 1-800-TOMCAT for sexxxy singletons in your area!), which will just inject a new function body into the server, so you can avoid having to re-deploy the whole application over a single changed line.
> Dealing with (somewhat) modern dataformats like JSON is is incredibly verbose (GSON, built-in, etc nothing compares to languages with what swift calls "subscribe", i.e user defined obj.blaha accessors instead of obj.getJsonValue("blaha")).
You're looking for Jackson. See the first example, "Full Data Binding". http://wiki.fasterxml.com/JacksonInFiveMinutes
If you need a little more flexibility than just "this object but serialized as JSON", you can control the binding with annotations or XML.
> Dealing with older dataformats like XML is incredibly verbose (never mind the gazillion XML <-> Object mapping frameworks with source generation pre-compilation stages, insanely long namespaced method calls, etc).
So you don't like writing it yourself (SAX parsers are verbose but fast and powerful), and you don't like the tradeoffs of letting tools do it for you, ok then...
JAXB isn't really as bad as you're making it sound though. And the rule of thumb is that virtually any awkward block of code can be stuck behind a convenient helper method and only touched directly if there is a very compelling reason.
> The static type system is actually just making the code very verbose without helping much because pretty much anything can still be null (again compare with rust/swift where static types + optionals means compilation actually provides some level of security).
Sure, object references can be null. Get over it, that's like CS 101 stuff right there. What do you think happens if you use an undefined variable in Python or Javascript?
If you really want to be sure that an object isn't null, just use "assert myObj != null;".
Again, static typing actually is a huge plus when you're looking through unfamiliar code and trying to figure out what it does. "What type of objects am I working with" is a fundamental question that you always need to know.
> It had massive corporate backing (Sun/Oracle) to instill the idea that pretty much anyone can learn programming as a trade (I've worked extensively in India with outsourced java-programming, and the quality of code produced by some people labelled "senior" is absolutely shocking. This is not unique to India however).
> Things like ORMs (Hibernate and EJB) meant most people j...
I think you missed the part where he's comparing against statically typed languages like Rust and Swift. He's not arguing against static typing. He's arguing that Java is both more verbose and less type-safe than languages like Rust and Swift, which both prevent null, and have type inference.
> Get over it
Why get over it when you can just use a language that doesn't let null leak into every reference?
Imagine the fun of doing that in C and C++ before Java was known to the world.
It used to be called COM, CORBA, OLE 2.0, DCOM, SOM.
Any language in a EE environment suffers from space architects.
Most of those things aren't even Java-specific.
IOC is just a design pattern that asks you to consider whether you should be writing a web server or, say, a request controller that runs on a web server. Since the web server invokes your controller method when it gets a request, we say "control is inverted", because the server is actually driving your application. You are surely doing something similar in any other language you choose, whether or not they tell you it's IOC.
As a whole - from the user (programmer) perspective, Java EE is in fact mostly just a collection of such IOC patterns that have been provided for you to "fill out". This is a servlet template, this is a filter template, etc...
XML is XML, nobody argues that it's not verbose, but it's not difficult to write. With a DTD file specified, an intelligent editor like IntelliJ will suggest element/attribute options for you, which is about as easy as it can get. It's certainly better than a properties file where you don't get any auto-suggestions, but if you want something a little more imperative you can also configure most components programmatically now (i.e. you get a configuration object that you can set settings on, then you call "build()"). Spring and Hibernate both support it, at a minimum.
Glassfish is just an application server. I don't use it, Tomcat is more than enough for most web apps and in fact you can usually get away with a "thin" server like Jetty in most cases.
Spring is such a broad topic that it's almost pointless to talk about. Are we talking about just Spring? Spring MVC? Spring Test? Spring Boot? Spring Security? Each of those solves something different, and frankly each of those also happens to do it much more cleanly and efficiently than anything that came before. Having worked with Struts and directly with low-level Servlets, Spring MVC is a breath of fresh air.
The basic Spring is just a dependency injection system. For most people, that boils down to a nice way to auto-build your ORM instance and inject it into your controllers. You can take it or leave it, it's about a page of code to replicate it in most applications, but it gets increasingly useful in more complex applications and with more complex use-cases because it lets you side-step the question of what environment you're running under in the code itself, and push that into configuration. You can run integration tests against a specific testing database, a SQLite you set up just for the test, etc, and the application doesn't need to know.
Maven is actually the most fantastic thing about the entire Java language. It's a universal project file format that is understood by every single IDE on the market, no more messing around with putting libs in classpath. It's also one of the few 100% reliable packaging systems that I've ever worked with, it will Just Work, 100% of the time, no matter your environment. I've spent so much time fighting pip and bundler over system libraries that need to be installed, 64-vs-32-bit problems, not liking cmd or Cygwin environments, etc. The only complaint I can make about Maven is that you can't just pass it a directory of libs and say "include these"... but it's very obvious why it doesn't do that, it kind of destroys the purpose of explicitly specifying your dependencies. The solution of declaring a local repository inside your repo is less than obvious, but it works. And again, on the whole it's much better than Ant. I would actually rather use a makefile than use Ant.
In general you're right that there's certainly tools that will let you overengineer things if you try. Who could argue with that in a world where AbstractSingletonProxyFactoryBean exists? A lot ...
Body: "Instead of arriving in March 2017, it has delayed, and the new schedule mentions a date of 27th July 2017"
Is there a better source for this material? The submitted article looks cribbed from elsewhere but I don't see a link to the original source.
http://openjdk.java.net/projects/jdk9/
EDIT: on my phone and meant to write monster.
2. Easy to find programmers?
3. Great networking and concurrency libraries?
4. Simple language with an amazing virtual machine?
5. Ecosystem has several good other languages that interop from good to amazing with Java including Scala, Clojure, JRuby, Groovy, and Kotlin.
After writing "good to amazing", you put an ordered list which many readers will subliminally rank in the order you provided, with the "amazing" languages on the right. I've tried 4 of those 6 languages, and would rank them in a different order.
> Ecosystem has several good other languages that interop from good to amazing
The ecosystem also has several other languages that interop from bad to amazing, just like other ecosystems.
[1]: http://whatis.techtarget.com/definition/Taco-Bell-programmin...
I find clojure a significantly better language, and theres always kotlin / scala if static typing is your thang.
People tend to conflate the not-so-nice java language with the good parts (libraries and JVM). The performance of the JVM and the same massive ecosystem of existing libraries are available in clojure, scala and kotlin.
Sure there are lots of goodies on user space, but there isn't any way around it, when you want to extract all juice from the platform.
- protocols have the same performance as interfaces but with significantly more power (solving the expression problem by default prevents so many headaches when you have to add more functionality later)
- loops and other binding constructs can have type hints to allow java-speed numerical operations
- immutability by default does have a cost in memory and cpu, but the ease and safety of concurrency it has enabled in my codebases more than makes up for it, e.g. "oh i've got a large (>100000 elements) of data being processed here in various ways (map, filter etc), lets parallelise that and give it a thread pool"
I feel that if I were truly performance constrained in clojure its likely I would have performance troubles in java, the difference is just not big enough.
BUT if such a situation came up, theres nothing to stop me coding up my super duper ultra performance needed code in java and just calling it from my clojure codebase. Interop is very nice.
YMMV but its never been an issue in my day to day work (mainly involves analytics, visualisation, web services)
1. Dependency management done right. Maven and Grade simply blast away most other dependency management systems. So yes, the code may be longer to write than other languages, but it's very easy to reuse code that's already written (by you and others)
2. Plenty of high quality third party libraries. Thank the enterprise, thank Android, thank whover you like: they just exist.
3. Stable APIs, libraries, and language. There have been very few occasions where backwards compatibility was broken in Java, and those were mostly very complex edge cases that occurred quite rarely. Nothing like py2->py3 btw. Sometimes slow is not so bad; it means you don't need to fix your code every 3 months because something changed upstream.
4. API/Interface first. Java encourages modularity and composition; J2EE may be a monster since it's comprised of dozens of interfaces, but it actually makes it very, very easy to "swap out" a single component with your own implementation without needing to rewrite/fork a whole library or framework. The way most things in Java work and interact are perfectly documented and standardized; combining even tens of different libraries is easy, you don't risk that each author has a different opinion on 'the right way to do it' that makes it not compatibile with the others.
5. Excellent tooling. Java IDEs are really advanced and can perform error-free refactoring and other operations on large projects.
6. Works on many platforms, in quite an expected and homogeneous way.
They aren't that hard to find.
i wonder when the Android ecosystem will support it.
- Java 6 and 7, not all of the APIs are supported
- Java 8, on top of not supporting all of the APIs, it doesn't support the new bytecodes and 100% of the language changes. As Android team puts it at Google IO, "tell us which features you care about", apparently 100% isn't a goal.
Also the new compiler toolchain required for Java 8 support, Jake and Jill, still doesn't work properly.
Also there are several issues, where Android has implementation bugs versus what Java libraries actually do, e.g. String::split.
Have fun browsing through the issues, https://code.google.com/p/android/issues/
In a 5 years time, more or less when Java 10, hopefully gets released, the fun of writing portable Java code between Android Java and standard Java will be even better.
but nowadays, I think having a common runtime plus a language that can exploit that is quite nice. having written some java lately, it was a refreshing break from the brutalism of C.
looking forward to whatever they bring to the table!
EDIT: java without any IDEs is also very usable. my workflow from small C projects didn't change. I don't bother with Eclipse, I just do all my work in my terminal.
http://www.beanshell.org/
Add bsh.jar and a little glue code and presto you have a shell into your application.
There was a Java-based editor, jEdit, which integrated with Beanshell. I could do search-and-replace with replacement programmed in Beanshell. Aah, these were good times.
http://openjdk.java.net/projects/valhalla/
No, it's not in 9. It may not even be in 10. Its current status is "Draft"
In the meantime, may I suggest alleviating the pain by using the great immutables library: https://immutables.github.io/immutable.html or Google's autoValue: https://github.com/google/auto/tree/master/value