Am an absolute beginner, trying to learn Java for quite some time but recently started serious studying.
My concern is that 90% of the books I have (dozens of books) are based on Java 7, I have two O'Reilly Java 8 guides but they are bridging materials, meaning I should already have vast knowledge of Java for them to be of any use to me.
To cut it short, would using Java 7-based books to learn Java be a problem now that Java 8 is released ? would I be missing something ? would it be easy to learn the new features in Java 8 later on ?
Note that newer versions of some of the books I have are in the making and are expected to be available by mid June.
Java 8 is backward-compatible with Java 7 (and with all previous versions, BTW). The only important things you'll miss are the lambda support, the Stream API, and the new javax.time API, that were added in Java 8.
But everything you'll learn with Java 7 will still be completely relevant in Java 8.
Related
I have an application written on Java SE 8 that was heavily using features for mixing Heavyweight and Lightweight components.
In particular, the function "SetComponentMixingCutoutShape" was used, which was later deprecated in future versions of Java.
Now I have an option to switch to Java 11 - and I run into a problem. Seemingly, there's simply no alternative for this functionality in later versions of Java. Or at least I couldn't find one.
So what does that mean - that I simply don't have access to that feature AT ALL anymore?
Thanks for replies!
As soon as I asked I found the answer.
The functionality has been moved to component class
Before you used to call setComponentMinxngCutoutShape(component, shape);
Now you need to go component.setMixingCutoutShape(shape);
Currently our applications runs with Spring Data Solr + Apache Solr 5.3 + Java 8
We are upgrading our systems to Java 11. Does Spring Data Solr & Apache Solr latest version support Java 11 ?
Solr 7.6 supports "Java 8 or greater". However . . . .
As per the Solr News it looks like 10 is tested and supported
Java is generally backwards compatible although Java 11 release notes might suggest has some backwards compatibility issues that might trip folks up in general
This ticket in the Solr Apache JIRA indicates that "Upgrading to a more recent Java (JDK 11?)" is open and unresolved
More definitively: As of late 2018, Java 11 was not yet recommended according to the good folks at LucidWorks. "The recommendation is to stay with JDK-8 until the Apache project officially supports JDK-11."
Based on the above it sounds like Java 8 is the safe bet, 10 might work but is risky and 11 is "right out" (h/t to Monty Python and the Holy Grail)
We are using Java 1.4 and we would like to push data to the ELK stack.
I checked their site and googled and its mostly turning up artifacts/articles
that need more than 1.5.Are they any options since we cant change the current
java version installed.
Regards
Java SE 6 was released in 2006 and if I remember correctly the minimum version for Elasticsearch (first public release in 2010) even in the early days has been that.
The oldest docs available on the Elastic website are for 0.90 and that is ancient. Even if you could run an older version, there are no docs for it, so you really don't want to go there.
While upgrading existing applications can be a challenge, it's still not possible to run new services on newer versions? Anyway, you need to get to Java 6 at the very least or rather 8 for current versions.
I hope this is not off-topic for SO (I hesitated between SO and programmers.stackexchange) but as far as I can tell this is a "practical, answerable problem that is unique to the programming profession" so it's complying with the FAQ.
Which version of the JVM do you need in order to run which version of Clojure (Clojure on the JVM, this question is not about ClojureScript)?
The page here: http://clojure.org/getting_started states that:
Clojure requires only Java 1.5 or greater
But is this always going to be the case?
And what about the Clojure ecosystem, like Leiningen?
Basically I'd like to know if I can count on Clojure to be able to develop a desktop app that should run on systems, including OS X systems, that are never going to get Java 6 nor more recent versions of Java (for example on some OS X versions Apple stated that no JVM 6 would ever see the light).
I am not on the Clojure/core team, so I don't have inside information, but here is how I would approach this situation.
Take the latest version of Clojure (1.5 as of this writing) and test it against Java 1.5 for the things you need to do and any Clojure libraries you need to use and stick with that. If Clojure 1.5 is Java 1.5 compatable, it will always be so, since that release is immutable.
I would not make the assumption that all Clojure versions after 1.5 will be Java 1.5 compatible and you definitely can't assume that Clojure libraries will be. For example, I just released a Clojure library that requires Java 1.7 (since it uses a java.util.concurrent class introduced in Java 1.7).
Since Leiningen gives you maven-like dependency resolution if you test all your libraries and your chosen version of Clojure against Java 1.5 and they work, then you can stick with that set of versioned dependencies for as long as you want to keep the app running. Your only risk at that point is that some bug fix releases of a non core library might not be Java 1.5 compatible any longer. This risk is proportional to how many non-core Clojure libraries you need to use.
If you are selective about what libraries you use, then targeting Java 1.5 is certainly feasible.
Clojure is very conservative about it's Java version requirements - hence the dependency on version 1.5 only.
Many libraries depend only on Clojure itself, so will run quite happily on the 1.5 JVM
Some libraries require >1.5, these tend to be more advanced libraries that have requirements for interop with specific Java features (e.g. newer concurrency code).
Note: I personally write all my apps/libraries to target Java 1.6, since I think that is a reasonable minimum and the vast majority of Java-based systems are at 1.6 or above. I'm willing to live with the potential loss of a few users who are stuck on 1.5. Also, even if a future version of Clojure does abandon 1.5, I expect it will continue support for Java 1.6 for a long time.
Notably, in Clojure 1.6 they have bumped the version of Java to 1.6:
The Clojure 1.6 Release Notes
include this ticket:
CLJ-1268: Require Java 1.6 as minimum for Clojure
So, "no" is the answer to the original poster's question of "But is [Clojure requires only Java 1.5 or greater] always going to be the case?"
We have a project which (assumed) would be finished in 1-2 years. By then, the JDK7 (and hopefully the Java7 JCP spec) should be ready.
But, I wonder, how probable is the "danger" that Oracle will make a "stupid" decision, which would make the JDK7 a less "attractive" platform then the existing JDK6?
More specific, I'm afraid of scenarios such as:
halting the development of JDK7 before it is "released"
changing the licensing model to be more restrictive than JDK6
...are there other scenarios to be aware of?
What is your opinion on the issue?
NOTE: We would use the NIO2 files API, and perhaps other JDK7-only features which were accepted for "Plan B" (Plan A was rejected, was a proposal to continue to develop JDK7 much longer, instead, Plan B was accepted: develop JDK7 with less features and postpone them for JDK8)
It depends on how many Java 7 specific features you use.
If your code can still compile on JDK 6, I'd say you're quite safe. You can run on JDK 7, since it's backwards compatible, but if there's an issue you can still deploy on 6.
If Oracle does something really stupid you'll have a bigger decision on my hands: Do I rewrite this app in C#, Python, or something else?
I'll be curious to see how well open source JDK will allow you to hedge your bet.
I'd also be curious to see which features of JDK 7 you're already using: closures?
If you're concerned about risks associated with Java 7, you can mitigate them by ensuring your code will run on Java 6. The easiest way to do this is to develop atop Java 6 now, then upgrade to Java 7 once those risks have dissipated.
In addition to the risks you've noted, the set of features planned for Java 7 is in flux.