Is latest version of jar support older version jar - httpclient

Is httpclient-4.5.2.jar backward compatible with httpclient-4.3.6.jar?
Same question also for httpcore-4.4.4.jar with httpcore-4.3.3.jar?
I have to use a newer version for supporting some functionality. but is there any impact of my older code?
Is those jar version controlling working conventional way for backward compatibility support like java JDK?

Short answer no. For minor upgrades (4.3.3 to 4.3.4) things usually work, but when you go from 4.3 to 4.5 you can expect changes. See release notes for hints about what you can expect.
Having said that, if you can compile without errors you are usually safe!

Related

How can I upgrade parse-server to a new version?

I have a few apps (already working) running parse-server on Heroku and using mLab mongoDB.
I need to upgrade parse-server to a new version.
What is the simplest (an best) way to do that?
Ensure compatibility by testing locally first, of course. To upgrade the version you change your project's package.json file. There should be a dependency "parse-server": "a.b.c"
"a.b.c" will use an explicit version.
"~a.b.c" will use the latest version matching "a.b."
"^a.b.c" will use the latest version matching "a..*"
a is a major version, which is not always backwards compatible.
b is a minor version, which generally includes new features but should be backwards compatible, so ^ is usually safe to use.
c is a patch version, which is generally bug fixes and security updates, though I think parse-server has included minor feature updates here as well.

Java 8 support in GWT

This seems like a very basic question, but I searched high and low and have found almost no mention of it anywhere. So, I'll ask it here here.
What is the current plan for supporting Java 8's new language constructs in GWT?
In addition, what subset of the proposed Java 8 libraries are slated for client-side emulation? The Stream API? The new Date/Time API?
And finally, where are the discussions relating this important topic taking place? I'm sure there are many of us who would like to participate in, and potentially contribute to, the effort.
The Java 8 betas have been around for a while now, and there are numerous articles discussing the proposed APIs. It is supposed to be related later this year, so it seems past time to at least be discussing how and when the much-desired language features will make their way into GWT.
My apologies if this question is answered somewhere else, or if I missed some important piece of information related to it. This would be a great place to have a link to such information, even if it has been answered. Thanks!
EDIT GWT 2.8.0 was released on Oct 20, 2016 with support for Java 8 language constructs (lambdas, method references) and emulation of some Java 8 APIs (streams mostly)
EDIT as of Apr 2014, GWT 2.6 supports Java 7, and work is underway to support Java 8 in GWT 2.7, to be released by the summer 2014. GWT 2.7 is likely to only support Java 8 language constructs though, and not emulate any new API (streams, javax.time, etc.)
The plan is to first support Java 7: https://github.com/gwtproject/gwt/labels/java7
This involves updating JDT, and this is being worked on (or alternatively, switch to something else entirely; JetBrains proposed using their parser which already supports Java 8, but GWT also needs a compiler and I don't know what they provide exactly). The next steps are to map new language constructs to JavaScript (strings-in-switch come to mind, as they could directly map to JavaScript without the hashCode-based desugaring that a Java compiler would be doing).
As long as GWT uses JDT for its Java parsing/munging/compiling, Java 8 can only be supported when JDT will support it (at an acceptable level, which is not yet the case AFAICT).
Time to update the answer.
UPDATE (May 13, 2020)
GWT 2.9.0 finally here. Release notes
Able to compile projects with jsinterop-base 1.0.0, elemental2 1.0.0, and jsinterop-annotations 2.0.0. With the exception of #JsAsync and #JsEnum, this brings GWT2 to be compatible across these tools with J2CL.
Added support for Java language levels 9, 10, and 11.
Officially, support is dropped for running the GWT compiler or server-side tooling on Java 7. The GWT distribution is still compiled to run on Java 7 for this release, but no guarantees are made about whether or not this will work. Future versions will compile bytecode for Java 8+. The release was tested and found to work cross platform when run with Java 8, 11, and 14.
UPDATE (October 2017)
GWT 2.8.2 available here. Release notes.
UPDATE (June 2017)
Official GWT 2.8.1 download location.
Release Notes for 2.8.1
UPDATE (October 2016)
GWT 2.8.0 is finally here!
The GWT team has released the 2.8.0 tag on Github. The official GWT website has not been updated yet, but a pull request for the changes on GWT's website is ready and in review process. So very very soon the compiled version will be available for download!
Available for download
UPDATE (September 2016)
Meanwhile, team GWT has tagged GWT 2.8.0 RC3 on GitHub mirror.
The GWT team (Daniel Kurka) has released the GWT 2.8.0 (RC2) version here.
The release notes are available for 2.8.0 (RC2):
Bug fixes
Fix incorrect unusable-by-js warning.
Fix an issue around DevMode server (jetty) restart.
Fix an issue in super dev mode with changing compiler options not triggering full recompiles.
Added missing command line parameters to DevMode entry point
Fixed a performance regression in String.
The release notes from RC1 are available on official website. Here are the most important changes regarding Java 8 support in the upcoming GWT 2.8.0:
Highlights
Partial support for Java 8 standard library APIs (see below for full list).
Fix memory leak with Java 8 compilation.
Source level set to Java 8.
Static and default methods in interfaces aren’t visible to generators. If you want to take advantage of those Java-8isms, you’re encouraged to switch to an annotation processor. This could break existing build if an interface is changed to turn a non-default method into a default method.
JDK 8 emulation support
Emulate java.io.UncheckedIOException.
Emulate Optional and its int, long, double variants.
Emulate Objects.requireNonNull() with message Supplier.
Fix Math.min/max(float/double) emulation behavior.
Emulate Character.isBmpCodePoint().
Emulate CharSequence.chars().
Emulate java.lang.SecurityException.
Emulate Java 8 API of
java.util.Arrays,
java.util.ArrayDeque,
java.math.BigInteger,
java.util.BitSet,
java.util.Comparator,
java.util.function,
java.util.Iterator,
java.lang.Iterable,
java.util.IntSummaryStatistics/LongSummaryStatistics/DoubleSummaryStatistics
java.util.Collection/Lists/Queues,
java.util.Map,
java.util.logging.Logger,
java.util.PrimitiveIterator,
java.util.Spliterator,
java.util.stream,
java.util.StringJoiner
The GWT 2.8.0 RC2 still has some issues, which the GWT team is expected to fix soon. The final release should be coming out soon ("as soon as it is ready").

Binary distributions of old (1.0 - 2.5) versions of Scala?

The Scala website says:
For historical and testing purposes, we also keep an archive of
previous releases (currently since version 2.5). Prior versions of
Scala, from 0.9.x to 2.4.x, have been archived offline.
Is there any way to get these versions? The source code is available in the git repo, but binaries would be nice.
EDIT:
I found some old versions at archive.org, but the oldest that I could get was 1.1.1.3 from http://web.archive.org/web/20040603140225/http://scala.epfl.ch/downloads/index.html
It turns out, if one looks hard enough, everything from 1.0.0-b4 can be found on archive.org. Unfortunately, some version in between are nowhere to be found, for example 2.3.x and 2.0.x. The question remains why they aren't published on http://scala-lang.org.

Upgrading Mercurial 1.5 to 2.2

I am upgrading my server from an old version of Mercurial, 1.5 to the newest version. I am wondering if the 2.2 build of Mercurial is stable for use by multiple users at a time. Also are there any gotchas when upgrading like my custom hooks not working, or a buildslave object not working? I have not done a major upgrade on a source control server before so help would be appreciated.
Mercurial is famouse for being very strict regarding compatibility. Have you checked upgrade notes? It list all breaking changes between version. Biggest change for me is introduction of hgweb in 1.6.
Biggest exception from compatibility rules are hooks. Mercurial doesn't guarantee anything so only way is to try.
Also consider making update in two stages. For example first to 1.9 and than to 2.2.

Vignette V8 Upgrade

Vignette upgrades are usually not straightforward. You basically have to do a new installation and migrate over all of your customizations etc. Does anyone know if the upcoming V8 version is easier to upgrade or if its easier to upgrade from a certain previous version compared to earlier version. So I can upgrade to an earlier version (say 7.6) and then hopefully its easier?
Vignette v8 is officially not out yet, its only been soft released to some selected clients. My guess is that the upgrade will not be very straightforward but I've no concrete information on that.
During the wait you might also be interested in an open source alternative of Vignette v8 freely available: Sense/Net 6.0 http://blog.sensenet.hu/post/2009/08/05/An-Open-Source-Alternative-for-Vignette-v8.aspx
I have finally found the answer. You do need to upgrade to 7.6 before upgrading to 8.0 from an earlier version.