Java 9 is scheduled to launch in July
freelancinggig.com
freelancinggig.com
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.
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.
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.
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 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).
These are personal problems (or actually, Personnel problems). No, Java doesn't somehow make chopshops able to magically turn out good code. No, it will not fix your co-worker who just doesn't understand how to write performant code. But he would be writing shitty code in Python or Ruby too, and you would have a whole set of extra problems on top of that.
> It's owned by Oracle.
Reminder: Google won their lawsuit. Oracle owns their Java implementation. They can't stop other people from reimplementing the Java API, however.
OpenJDK seems to be fine. I run it on Linux environments because Oracle JDK isn't in the repos, and it's pretty much a drop-in replacement in most cases.
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 of this comes out of patterns promoted in the book Effective Java, which is pretty much the definitive tome on the subject and is actually mostly very sensible stuff. But people read "maybe think about using a builder instead of getters/setters", totally miss the point (making objects immutable) and run with it, and soon you've got BuilderBuilderFactory and all kinds of other nonsense floating around just because they're blindly following the pattern instead of thinking it through. The actual problem in Java is that there's 20 years of such cruft and mistakes built up in some frameworks, but other languages are not free from the same effects.
The key is figuring out what subset of features and patterns you actually need and ignoring the rest. Java is not a one-size-fits-all solution where "There's Only One Way To Do It", it's a massive toolbox and you probably aren't going to need those Torx screwdrivers to change your oil. If you try to use everything in every project just because it's there, you're going to have a bad time. But you can rest assured that you have options if you ever need them.
If you're looking for a curated system of tools that are known to work well together, I urge you to consider Spring. Spring MVC is your equivalent to Rails, running it in Jetty is usually more than enough for basic web apps. The Apache Commons libraries are also very good for taking the edge off of some of the verbosity (they provide high-level equivalents to common operations on low-level objects), and are very high quality in general.
Also, to agree with a sibling comment, IntelliJ is definitely the way to go. Jetbrains stuff is just always so perfectly on the money.
Look it up, its nice.
Python has a pretty tedious class definition syntax too, and nobody ever accused Python of having a bad REPL!
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.
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.
They aren't that hard to find.
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.
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
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.