I remember issue then I could not perform build with old version 0.7 of Gradle when my colleague was using 0.8...
So was Gradle syntax frozen with version 1.0?
I didn't find such statement in release note...
The 1.x series will see major new features (for example parallel build execution) while at the same time retaining backwards compatibility with 1.0. Once we make the jump to 2.x (which we don't plan to do anytime soon), certain 1.x versions will still be supported for an extended period of time (long-term support model).
It has no evidence. I didn't see any information about frozen api
Related
I would like to use a Java library (SpringBoot) in latest version (2.0.0.M6), but I prefer to use only releases. So what means this "M6" in the library version? Is it a pre-release?
Thanks!
It is a Milestone release. The version includes some set of functionality that were released as soon as that set of functionality was complete.
In some organizations, this is considered pre-alpha software, where an alpha release is the first phase to start white-box, and possibly black-box or grey-box testing techniques.
Since these milestones have a number associated with it, this is the sixth milestone. What that means is entirely dependent on the project, and its development / release plan.
For spring-boot specifically, they targeted the completion of these issues to state that they had "achieved" 2.0.0, Milestone 6.
https://github.com/spring-projects/spring-boot/milestone/92?closed=1
In any case, this is pre-release software.
I have to maintain legacy product using JavaCC v4, what are the changes from then to v6?
I plan to use the v6 documentation, latest Eclipse plugin etc. I wanted to know what are the changes from JavaCC v4 to v6. I do not plan to upgrade the code, as I said it is legacy code that is being maintained.
I tried looking into the JavaCC v6 Release Notes, they almost make me feel that the only changes were addition of C++ support. Is that true?
I am a new to JavaCC, I have worked to some extent on on ANTLR, Flex/Bison.
I presume you are referring to the release notes page. I think there is more to it than that. I found release bundles for 4.1, 4.1d, 4.2 and 5.0 in the javacc downloads area. If you are looking for a detailed listing of what changed, you probably need to download each of the releases and check their contents for Release Notes / READMEs / whatever.
(Alternatively, trawl through the issues that are marked as "fixed" in the respective release milestones. There are example issue-tracker links in the release notes page; see above.)
But you can probably get away with treating 6.0 as a drop-in replacement for 4.0. IMO, it is worth just giving it a try. If anything has changed in ways that are not backwards compatible, your "plan" may be thwarted. So you may as well be optimistic about it ...
in detail:
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
Also , what is the combability rule between different updater versions , for example 1.6.22 and 1.6.23 what can not be changed, what can be changed?
of course, public API definition can not be changed, how about others? javadoc? internal API definition, implementation?
It will be great if someone can point a concrete official document on this topic. thanks,
there is one example in java document bug, that they intended not to change between updater version. see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6475885
this should be one of its big picture, but we better to have a complete description on this.
need to know the complete story so that we feel safe to upgrade to bigger version.
The general rule is that any code that is written and compiled against the APIs of Java X should run on Java Y where Y >= X.
There are occasional exceptions to this; e.g. where the application's behaviour depends on some undocumented behaviour (typically a bug) in Java X that was corrected in a later version.
AFAIK, there is no single document that lists these incompatibilities. The release notes for all of the Java major releases include a list of changes that could result in breakage of older code.
Having said that, the prudent approach is make sure that you thoroughly test / retest your software when you upgrade to a more recent Java release. And if your software is shipped to customers / clients, let them know if / when it is safe for them to upgrade, and (if necessary) provide them with fixes for any problems that your testing has uncovered.
need to know the complete story so that we feel safe to upgrade to bigger version.
Feeling safe is beside the point. Thoroughly test your application on the later version. That is the only practical solution. And that would be the case even if each and every incompatibility was exhaustively documented.
Think about it. How can you know for sure that your application won't somehow be affected by change XYZ? Or that some 3rd-party library that you use won't be affected? Answer: you can't.
No manner of complaining here that you think that Oracle should handle this issue differently is going to make any difference. Not that I think that they could handle this better without changing their business model. How much would you be prepared to pay for a Java platform that guaranteed there were no version compatibility issues?
This is not a full answer but I will add that will-it-run and will-it-compile are two different things. Keywords introduced in 1.5 will prevent some 1.4 code from compiling but the byte code will run just fine.
Almost anything can be changed between versions there are no set rules for such things. Use the release notes to publish changes or review them between versions such as:
http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
Usually only bug fixes are the cause of minor versions (like you detail 1.6.22 - 1.6.23), or simple enhancements which are only ever good things. When the major version numbers change then you can expect more major changes but you still "hope" for reverse compatibility.
I don't think JDK ever changes an API that breaks backward comparability (except unintentionally).
They introduced #deprecated tag in the very beginning, probably thinking that they may need to do some API cleanup in future. But that never happens. No #deprecated API has ever been removed, or behavior changed.
if we use public API for example, write java program for example , in JDK 1.4, if should run correctly in all version above it. in all update version in 1.4, in 1.5, 1.6 and 1.7?
See this table, that shows breaking changes in public jdk APIs
See these official documents about versions compatibility:
Java SE 7 and JDK 7 Compatibility
Java SE 6 compatibility with J2SE 5.0
Incompatibilities in J2SE 5.0 (since 1.4.2)
Java SE 1.4.2 Compatibility with Previous Releases
Are there any known security issues with compiling against an older JDK? For instance lets say Oracle decides to change something in one of their implementations that was to close a security vulnerability. If we compile against the older JDK would we still be vulnerable?
EDIT
We are running against JDK 6 and we compile against Java 5, which is the crux of the issue I was attempting to get at for any one else whom sees this question. For the sake of completeness lets say that in the ant build we target 1.5
EDIT 2
Additionally there is the issue of calls in the application that potentially have private APIs/implementations that are not directly accessed.
Aside from some very hypothetical niche situation that hasn't ever happened yet, the only thing that matters is the version with which the application is executed.
I don't think there are any known security issues that have been "fixed" with #deprecated, because that wouldn't really be appropriate.
There are two issues at play here:
1) You can have your Java compiler produce binaries that are binary compatible with older versions. That affects the language features available to you.
2) You can compile against the Java system libraries of an older version, and that will affect what methods/classes are available, as they are always adding new ones.
But neither of these affects the security of your application. What matters is the runtime version with which the application is executed.
Observe that security problems are fixed between updates, not the major versions, which introduce changes in the language itself. For example, Java 6 is currently at update 21. Java 6 update 19 fixed stuff that was vulnerable in Java 6 update 18.
When Java 6 update 19 was released, updates were released for Java 1.5 and Java 1.4, to fix the same issues in Java 1.5 (update 24) and Java 1.4 (update 26). See the security baseline table here: http://www.oracle.com/technetwork/java/javase/6u19-141078.html
If you compile against JDK 1.5:
Users that are using JRE 1.5 will be vulnerable
Users that are using JRE 1.6 will not be vulnerable
The application will run using the libraries of the users's runtime. Since the vulnerabilities are fixed in Oracle's library, which is now being called by your application, the security vulnerability will be alleviated.
However, since you compile against 1.5, your users will be able to use 1.5. Do anything you can to avoid the vulnerability; if you can't avoid it, detect the JRE version at startup and issue an alert if apporpriate.
If Oracle changes an API (not an implementation) to promote security, they will probably add an #Deprecated annotation but preserve backward compatibility for some time. The annotation will trigger a warning in a newer compiler, but not in yours, and not in the compiled program. (Unless Oracle decides to throw an exception or log a message from the deprecated method.)
I would say that those unfixed vulnerabilities are still there, and you and your app are still at risk.
It'd be the same issue as running with an old, unpatched OS or browser.
It's a good incentive to migrate up to newer JVMs.
We provide a popular open source Java FTP library called edtFTPj.
We would like to drop support for JRE 1.3 - this would clean up the code base and also allow us to more easily use JRE 1.4 features (without resorting to reflection etc). The JRE 1.3 is over 7 years old now!
Is anyone still using JRE 1.3 out there? Is anyone aware of any surveys that give an idea of what percentage of users are still using 1.3?
Sun allows you to buy support packages for depreciated software such as JRE 1.4. For banks and some other organizations, paying $100,000 per year for support of an outdated product is cheaper than upgrading. I would suggest only offering paid support for JRE 1.3. If anyone needs support for this, they can pay for a hefty support package. You would then shelve your current 1.3 code base, and if a customer with a support contract requires a bug fix, then you could fix the 1.3 version for them, which would likely just mean selectively applying a patch from a more recent version.
Even JDK 1.4 reached the end of its support life in Oct 2008. I think you're safe.
But don't take it from me. The people that you really need to ask are your customers. Maybe putting a survey up on your download page and soliciting feedback will help. If no one asks in three months, drop it.
Why not have your program report back what version of Java it is being run with. This will give you an idea of your user base.
I highly recommend dropping support for Java 1.3, and instead of doing a minor upgrade to Java 1.4, why not use Java 1.6? There have been massive improvements since 1.3. You really are missing out.
End-of-life is normal part of software's life cycle.
The real question you should ask/answer is whether you have a compelling business need to add features to the "old" versions. If not, you can continue to offer it for customers who need it -- but encourage everyone else to take the latest & greatest which requires 1.4 (or 1.5/1.6).
It's difficult to give figures for what companies use internally. There do exist figures for browser plugin installation, but Sun's figures are confidential.
1.3 support stopped some time ago (Solaris 8 vintage support dragged on for a bit). 1.4 has completed its End of Service Life, but is likely to be supported under Java for Business for yonks. IIRC, if you try to download 1.4 from the archives at sun.com then you are asked for some information such as an e-mail address. 1.5 is more than half way through its service life (but its still quite common on Macs).
It's not that difficult to use 1.4 features optionally. You just need to load one class via reflection (or just package it differently) and then have a 1.4 and 1.3 implementation of a light abstraction over the new features.
Why not only do critical patches for 1.3 & 1.4 if anyone actually requests them and do all new releases on 1.5 - the current oldest version supported by Sun?
I was developing with jdk 1.4 for a long time while jdk 6.0 was out. We couldn't upgrade(clients this, servers blablabah). At some point, we just upgraded without talking too much about it. Clients upgraded without being annoying, "this upgrade will fix lots of security holes, many bug fixes, improved performance :-)".
Right now, I try to keep my code compatible with jdk 1.5, I have no concern at all for people running 1.4 and below. At some point, they'll understand that it is in their best interest to "try" upgrading.