Still wrapping my head around Java 8 *sigh*
Oracle on Tuesday delivered Java 11, in keeping with the six-month release cadence adopted a year ago with Java 9. It is the first "Long Term Support" (LTS) release, intended for Java users who prioritize stability over Zuckerbergian fast movement and breakage. Oracle said it will offer commercial support for Java 11 for at …
Wednesday 26th September 2018 07:27 GMT Dan 55
Wednesday 26th September 2018 09:09 GMT Old Coot
This was always in the cards
I hate to say it, but this was predictable from the moment that Oracle acquired Java. Unlike Sun, Oracle gives nothing away.
The surprise is that it took them 10 years to spring the trap; I suppose they wanted as many projects as possible to wander in. But the rate of in-wandering seems to have hit an inflection point.
My own experience is that Java is now moving to legacy status (like the Oracle RDBMS); lots of installations, but declining take-up by new projects. Thus, a logical time to demand fees.
Wednesday 26th September 2018 09:14 GMT Anonymous Coward
Oracle have no idea what they're doing.
We've been flogging a commercial Java API for 20 years and have played catchup with Java versions the whole way. However we have literally zero interest from customers for Java 9 and 10, probably due to the absurd 6 month release cycle they came with. Java 9 was EOL before we even downloaded it.
Java 11 will be the first LTS version, although what that means in practice I don't know. So we anticipate a bit of interest in this release. Although with Oracle's license changes, frankly I'm not even sure about that. I have no idea why they bought Sun - they killed the hardware, now they're trying to strangle the software.
Wednesday 26th September 2018 09:21 GMT iron
They've managed fewer improvements in 6 months than Visual Studio & .Net had in the last month.
"There are a handful of useful language additions like new string methods for removing empty spaces – strip(), stripLeading(), stripTrailing() – and determining whether a string is empty or not – isBlank()."
Java didn't have those yet? ROFL
Wednesday 26th September 2018 11:29 GMT Blank Reg
Wednesday 26th September 2018 11:56 GMT Brewster's Angle Grinder
Unless they're numpties (and this is Oracle, so I don't discount that) a regex will be slower and use more memory than a dedicated function.
In C, stripping leading whitespace is something like:
while (isspace(*str)) ++str;
By contrast with
string.replace(/^\s+/,'')the compiler parses the regex into an internal representation, and then, at run time, that's passed to the replace function which evaluates it using an internal engine and splices replacements into matching substrings. It's just no comparison.
Wednesday 26th September 2018 12:05 GMT horse of a different color
Wednesday 26th September 2018 12:58 GMT Brewster's Angle Grinder
I presumed the work involved in string reallocation would be the same for both approaches and so excluded the substring step for clearer exposition.
But, because I've not had to code pure C in a long time and there is a certain delight in being able to do this stuff, I think it should be:
char* res = malloc(strlen(str)+1);
return res != NULL ? strcpy(res,str) : NULL
Thursday 27th September 2018 19:23 GMT Michael Wojcik
That's just strdup()
It isn't, actually. BAG's code (which isn't how I'd write it, but no matter) uses only functions and macros defined by the C standard, assuming a hosted implementation and the proper headers included.
strdup is not in the C standard, and in fact is in violation of it, because external-scope symbols beginning with "str" followed by a lowercase letter are reserved. See e.g. ISO 9899-1999 7.26.11. (I don't have the C11 standard handy to cite it.)
So a given implementation may not have strdup, and even if it does, it shouldn't be used if you want conforming code.
And this, of course, is an example of the #1 problem with C: Most of the people who use it don't actually know it.
Wednesday 26th September 2018 23:20 GMT ibmalone
It'll do the job when combined with the previous increment loop, not sure if the downvote is for avoiding strdup (POSIX extension, not standard C) or someone took exception to using NULL (nonstandard macro in C) rather than 0. It does assume nul terminated strings, but this is the C-string world, so if that's wrong you're dead already. Not a big fan of returning a ternary expression containing a function call, but each to their own...
For extra code golf points, the return line after malloc:
return res ? strcpy(res,str) : res;
as null/non-null pointers evaluate as false/true.
For GNU or BSD programmers (and keeping terseness, but don't be afraid of verbosely testing return vlaues!), all the code to allocate and copy str:
return asprintf(&res, "%s",str) == -1 ? 0 : res ;
As mentioned, strdup will do this particular job, but asprintf is so handy for other stuff to help make C string handling safe that it's worth the (minimal) effort of providing your own implementation for other platforms.
Thursday 27th September 2018 19:33 GMT Michael Wojcik
NULL (nonstandard macro in C)
It most certainly is not. Hosted implementations must define NULL in stddef.h, stdio.h, and stdlib.h (suppressing duplicate definitions, since more than one of those may be included in a translation unit), and it must be defined as an implementation-defined null pointer constant. (This is per C99, ISO 9899-1999; see appropriate sections of chapter 7. C90 required that NULL be defined as either 0 or 0 cast to void*.)
It takes very little time to consult the standard, assuming you have a copy. If you don't, why are you pontificating on what is standard C?
asprintf is so handy for other stuff to help make C string handling safe that it's worth the (minimal) effort of providing your own implementation for other platforms
Implementing a correct, conforming asprintf is not trivial. va-restarting is required (since you can't determine the length of the allocated area and do the formatting without at least two calls to vsnprintf), and most people get that wrong. vsnprintf itself requires a conforming C99 implementation, and some C implementations (hello, Microsoft!) have only recently provided one that actually follows the standard; if you have to support such backward implementations, you need to work around bugs in their vsnprintf or supply your own (definitely not trivial).
Friday 28th September 2018 12:29 GMT ibmalone
(This is per C99, ISO 9899-1999; see appropriate sections of chapter 7. C90 required that NULL be defined as either 0 or 0 cast to void*.)
It takes very little time to consult the standard, assuming you have a copy. If you don't, why are you pontificating on what is standard C?
Fair enough, I got it wrong. A decade since I've written C with a copy of the standard beside me. Pontificating though? It was a brief aside attempting to understand why someone might have downvoted an unobjectionable post. For that at midnight I'm not going to go hunting for draft versions of the standard (official ones being fairly expensive) to check.
Implementing a correct, conforming asprintf is not trivial. va-restarting is required (since you can't determine the length of the allocated area and do the formatting without at least two calls to vsnprintf)
Bingo, but non-trivial in an "I might have to take an afternoon once to get it right and write a test for it" way, rather than "it's going to take three months". There are liberally licensed implementations out there to use or refer to if needed, and one of the brilliant things about functions is that you only need to write them once. If you want pontificating, if the standards committee hadn't been so resistant to string allocating functions then string overflows would be a lot less common (and maybe more memory leaks...).
snprintf itself requires a conforming C99 implementation, and some C implementations (hello, Microsoft!) have only recently provided one that actually follows the standard
Of course C99 will be celebrating its 20th birthday in a year or two (depending when you count from).
Wednesday 26th September 2018 18:09 GMT JLV
eh, eh, I do know, and appreciate, regex - and often see them underperforming index or pos-based string manipulations... Not surprising, if you look at the state-machine underpinnings of regexes. They’re a brilliant tool, for particular cases.
As a wit once said:
“You have a problem. Which you’re going to solve with regex. Now you have 2 problems.“
Strip blanks with regexes cuz the #1 language took 23 years to have String.strip??? Do you know how error-prone and perf-stupid that is?
Wednesday 26th September 2018 12:19 GMT Allonymous Coward
I recently had an unrewarding conversation with one of our managers about this. We run a lot of our existing stuff on OpenJDK via Ubuntu. It's worked well for years, but people are starting to do the usual headless chickens impression about moving to Java 11 because what if there's a security hole in February 2019 etc.
I suggested maybe using AdoptOpenJDK to give us a longer timeline on Java 8 but apparently that makes our managers "nervous" because you're reliant on an upstream volunteer effort to release patches. I pointed out that's what we do already but I don't think it reassured them. Perhaps if AdoptOpenJDK had a more "Enterprise" website or something. Anyway at that point I decided to shut up before they made us move to Solaris too.
Sometimes it depresses me how little these people have learned about open source. On the bright side I'm out of that job at the end of the year so won't be around when the smelly brown liquid (coffee, what did you think?) hits the fan.
Icon, because Oracle.
Wednesday 26th September 2018 14:07 GMT Maelstorm
#1 Programming Language? Think again...
Our programming language is still number one, insists database goliath.
I disagree. Java is a piece of shit language with delusions of grandeur. It thinks it's a real programming language like C++, but when in fact it's the schoolyard bully, and it fails even at that. It's slow and cumbersome. It's only saving grace is that it is platform independent.
Wednesday 26th September 2018 14:11 GMT Anonymous Coward
Color me confused
So let me see if I understand this...
We don't use Java much, but have a couple of admin tools that insist on it. So my choices are, stick with version 8 and get no security updates, move to 11 (and pay Oracle?) or switch to the OpenJDK. I'm only talking about the "Java for Windows" runtime - we don't do any development - so do I have my choices correct? Is it as simple as uninstalling Java 8 and installing the OpenJava for Windows equivalent?
Thursday 27th September 2018 19:40 GMT Michael Wojcik
Re: Color me confused
If memory serves - I've been reading about and discussing this ad nauseum for months and by this point I'm not sure I remember what's confirmed and what was just rumor - yes. For Windows JREs, your choices are:
- keep what you have, and hope you never need any fixes
- get Java 11 from Oracle without support, and hope you never need any fixes
- pay Oracle for support
- switch to an OpenJDK build
Regarding the last, there are a couple of prominent OpenJDK builds for Windows. There's the one from AdoptOpenJDK, which is free but 64-bit only and currently lagging behind Oracle. AdoptOpenJDK is pretty well funded and the expectation is they'll get their processes ironed out and catch up, but some people are nervous about whether that will happen on a schedule they're comfortable with.
Then there's the build from Azul, which comes in the free Community version (only community support, should get security fixes, no guarantees) or the paid version which is fully supported. If memory serves, Azul provide a 32-bit build as well as 64-bit.
You don't want to try to build OpenJDK yourself. It's reported to be relatively difficult, and the OpenJDK distribution lacks a number of key pieces that have to come from elsewhere. Also, testing against the TCK to validate your build is a major effort; that's one of the main benefits of using someone else's.
Wednesday 26th September 2018 14:43 GMT Anonymous Coward
Would someone please explain how the desktop JRE licensing will now work?
My company doesn't program anything and we own no apps that require the JRE. But we do download a lot of PDFs from government websites and many of them require the JRE to view them. We also have some Cisco stuff that requires it.
I have never found any licensing docs for the JRE, just all of the other alphabet stuff, SE, SDK, etc. I have never understood the relationship.
As an aside, one thing missing from most of the post Java 8/1.8 discussions is that it is the last version where the JRE is available in 32-bit. I'm wondering how much havoc that will wreak.
Thanks for any help you can provide.
Thursday 27th September 2018 11:08 GMT Dan 55
Re: Would someone please explain how the desktop JRE licensing will now work?
It seems updates will continue for personal users but stop for business users. This is supposed to explain, but it doesn't say how that happens or how the Java updater can do this.
if it's anything like the closed-source VirtualBox plugin, Oracle will log the IPs which download Java packages, try to resolve them to a business, if they do find a business then go after them after a while with a bill which they either pay or contest.
So there's a possibility that if if you're in a business and you don't turn the updater off by the end of December you just walk into a trap.
Thursday 27th September 2018 16:45 GMT mfarah
String.strip() and String.trim()... but still no built-in vain string testing or a proper split().
String.split(), as far as I can tell, is still broken. Probably impossible to correct it at this point without "breaking" a lot of other stuff, but so far no interest from anyone to add String.properSplit() or something.
And I still think it'd be a good idea to add the static isVain(s) method (returns true if the given string is either null, "", or "" AFTER being trimmed by .trim()). It'd be a small addition, but it would help clean up SO MUCH code everywhere...