"Efficiency" is all about tradeoffs, and the "best" algorithm will depend on many factors. In the case of indexOf()
, one of those factors is the expected size of strings.
The JDK's algorithm is based on simple indexed reference into existing character arrays. The Knuth-Morris-Pratt that you reference needs to create a new int[]
that's the same size as the input string. For Boyer-Moore, you need several external tables, at least one of which is two-dimensional (I think; I've never implemented B-M).
So the question becomes: are allocating the additional objects and building lookup tables offset by the increased performance of the algorithm? Remember, we're not talking about a change from O(N2) to O(N), but simply a reduction in the number of steps taken for each N.
And I would expect that the JDK designers said something like "for strings less than X characters, the simple approach is faster, we don't expect regular use of strings longer than that, and people who do use longer strings will know how to optimize their searches."
This is explained in much details at OpenJDK page: JDK 7 Update Project Proposal Q & A
Will this Project serve as the basis for Oracle JDK 7 Update releases?
Yes.
To quote from Joe Darcy's FOSDEM blog post on OpenJDK 6:
In particular, there will not be the same dichotomy between the OpenJDK 7 code base and the 7 update code base as there is between OpenJDK 6 and the 6 update train...
Per my reading, above essentially means that patches and updates will typically go first to Open JDK and then, with as small delay as possible, delivered in Oracle JDK.
For security patches, the picture seems to be opposite, ie I'd rather expect them to go first to Oracle releases and then (again, with as small delay as possible) to OpenJDK:
Will the 7 Update Project receive security fixes from Oracle?
Yes.
As with OpenJDK 6, security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to affected JDK release trains. In addition, they will not go through the public code review and putback approval process, and their corresponding issues in the Project's issue tracker will not be publicly visible.
When will this Project receive security fixes from Oracle?
The schedule for Oracle Java SE Critical Patch Updates is publicly available.
Security fixes for this Project's source code will be made available in the JDK 7 Update Project around the same time as they're released in products from Oracle...
To better understand the reasons why there seem to be so much effort put into keeping Oracle and Open JDKs in sync, it makes sense to take a look at the Oracle decision on preceding project: Moving to OpenJDK as the official Java SE 7 Reference Implementation:
...Oracle and the other members of the Java SE 7 Expert Group have been putting the finishing touches to the Java SE 7 specification (JSR 336). In its role as the specification lead, Oracle is responsible for delivering the Java SE 7 Reference Implementation... we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license.
The role of the Reference Implementation (RI) is to be used as the gold standard for all Java implementations. In order to have an implementation certified as Java SE compatible, an implementor must pass a large number of compatibility tests - the Technology Compatibility Kit (TCK). Furthermore, implementations may be compared to the RI as an additional check of compatibility. Basically, if your implementation has been certified to have the same behavior as the RI then it is Java compatible. For more information on this topic, consult the JCP FAQ.
Historically, Sun always used the Sun JDK as the RI and made it available under the Binary Code License (BCL). This was very convenient for Sun since it meant that its product implementation was compatible by definition. However, it was also confusing since the Sun JDK contained quite a few features that were not part of the standard, such as the Java Plugin. Also, continuing this practice would make things difficult for open source implementors as they would not be able to study and evaluate the official RI source code. (The source code for the Oracle JDK is slightly different from OpenJDK - something we will be addressing moving forward).
With that in mind, Oracle will:
- Create RI binaries based only on the OpenJDK code base.
- Make RI binaries available under the BCL (the normal Java license) for commercial implementors and GPLv2 (with the Classpath exception) for open-source implementors.
- Continue to provide the TCK to commercial licensees, but also update the OCTLA license so that it covers Java SE 7. The latter allows open source implementators gratis access to the TCK to verify their implementations...
Above decision means a lot of effort to put into Open JDK code, to release officially verified, tested, licensed and compliant code. If you add that it has to be released following the agreed public schedule, it becomes obvious that such an effort will be about the same as previously was put into "traditional" Sun/Oracle Java releases.
This makes it only reasonable to keep Open and Oracle JDK code bases as close as possible: otherwise, duplication of development and fixes to make both projects compliant with TCK could become prohibitively daunting.
It looks like decision to use Open JDK as a Reference Implementation made it in the best interest of Oracle to keep their JDK as close as possible in sync with Open JDK - up to release of JDK 7.
To understand what could motivate Oracle to keep mentioned sync further, with JDK 7 update releases, one would better take a look at the Open JDK 8 project, which purpose is described pretty much similar to that of Open JDK 7:
The goal of this Project is to produce an open-source reference implementation of the Java SE 8 Platform, to be defined by JSR 337 in the Java Community Process.
For the same reasoning as was explained above regarding reference implementation of JDK 7, it is, again, in the best interest of Oracle to keep the updates of both JDKs as much in sync as possible.
The more differences would be between these JDKs now, the harder would it be for Oracle to release Java SE 8, due to duplication of efforts necessary to bring their own release into compliance with TCK. The opposite is also true, ie the closer both projects are going to be now, the less effort will be required to release both Java 8 implementations.
Did it ever happened to you to support in parallel two slightly different versions of the same software, targeted at different clients? If yes, you likely remember the desire to keep them both as close as possible, and the inconveniences you experienced when these were out of sync. With Open and Oracle JDKs, it is pretty much like that, only on a larger scale.
Best Answer
According to Java Docs: About
nextInt()
This method consumes the integer, but not the new-line character or other character after that integer. So after consumption of integer by
nextInt()
, there only remain newline character (In this case) as entered by keyboard or file. It cannot discarded bynextInt()
. Thus\n
staying on the buffer.And description of nextLine() says
As we expected by
nextLine()
, it consumes the new-line character that was not consumed bynextInt()
. But when it return it exclude newline so returned string bynextLine()
becomes empty.