Everything About Java 8 233
New submitter reygahnci writes "I found a comprehensive summary of the developer-facing changes coming in Java 8 including: improvements to interfaces, functional interfaces, lambdas, functions, streams, parallels, date/time improvements, and more. The article includes example code with realistic examples of use as well as explaining the reasoning behind some of the choices made by the developers who are working on Java 8."
New Features of Java 8 Summarized (Score:5, Funny)
Highlights of Java 8 include
Green solutions. Advanced power management features, and automatic tracking of each thread's carbon footprint. An console allows users to see the carbon footprint of each thread in real time.
Social networking. Users can share jar files on social networks, and like their friends jar files.
Cloud computing. Java 8 will be the first VM built for the cloud.
Re:New Features of Java 8 Summarized (Score:5, Funny)
You forgot Big Data. Java 8 is built to support Big Data!
Re: (Score:2)
Changes (Score:4, Interesting)
That said, I'm somewhat concerned about some of these changes. Lambda functions are great, but one of the benefits of functional programming is the lack of side effects. Under the Java 8 design, lambda functions allow you to modify member variables, which means that benefit is completely gone. This means lousy programmers will be able to write incredibly complex code, with strange side effects, that is hard to use.
The new streams functionality is fine, but did they really have to call it streams? When there are already Streams in Java?
String.join() is great. Finally.
The new Date library looks fine. It better be good enough, because do you really want yet another Date system added into Java?
Re: (Score:2)
Most decent Java programmers have been using Joda for years. This is just bringing in something that is standard practice.
Re: (Score:2)
Uhm. I think I'm a decent Java programmer and I haven't bothered to use Joda ever. Not every problem involves handling dates.
Re: (Score:2, Insightful)
Lambda functions are great, but one of the benefits of functional programming is the lack of side effects
What people want is to pass a callback to something and then play with members from within the callback, and do so --> WITHOUT <--- having to create a single use method with some pathetic name in some other place inside the class. Your supposed 'benefit' is exactly the opposite of the intent. ECMAScript 6 specifies 'fat arrow' functions for the same reason; lambda's that easily expose the outer context to the body of the lambda so we can all stop doing var that = this.
Lambdas are perfectly legitimat
Re: (Score:3)
This is what I like in Java in comparison to other languages: the language moves slow, the JDK moves slow, but you have for everything open source libraries and tools. Unlike C or C++ I can mix those libraries without any hindrance, because the basic types are fixed in the Java language: String, primitives, etc.
Call me old-fashion, but I like that the language is evolving slow. In Java I can use Groovy, Scala, Python, Ruby, JavaScript, etc. if I want "modern" features, like closures, lambdas, etc. Plus I ha
Re: (Score:2)
My wish list would be: more polish for Swing, new widgets in Swing, faster JVM, smaller JVM,
Yeah, now those are some real changes that would be more practical.
Re: (Score:2)
People have wanted that for more than a decade; don't hold your breath.
Re: (Score:2)
Java has been evolving quite rapidly, with major new language features in every major release.
Re: (Score:2)
I agree. An often overlooked thing in language design is that less functionality leads to more standardized code that's easier to read. When I want to use complicated languages there's already a wide selection available.
Why continue with Java (Score:2)
as all it seems to be doing now is playing catchup to something like Scala which has at least thought out the functional stuff maybe a bit more
Could Project Lambda be axed? (Score:2)
Java needs explicit operator overloading (Score:3)
Only thing I want to know is (Score:3)
does it break backwards compatibliity with 7, like 7 did with 6?
that's been one of my major gripes about Java, write once, run anywhere until the jvm version changes, then you can be screwed.
Re: (Score:2)
Re:The important bit (Score:4, Funny)
After all the security vulnerabilities patched this year, I would think they're feeling the pressure to make sure there isn't a repeat.
Normally one would think that, but this is Oracle we're talking about.
Re: (Score:3)
Re:The important bit (Score:5, Informative)
This is about Java the language, not Java the browser plugin. You should know the difference by now...
Re: (Score:3, Informative)
This is about Java the language, not Java the browser plugin. You should know the difference by now...
I've been misinformed then, I thought the security vulnerabilities in the java plugin were inherited from vulnerabilties in the way the language itself handled data. Someone mod up the guy above.
Re:The important bit (Score:5, Informative)
No Java itself is used in so many places. Your phone probably uses it for a start. From the cheapest old fashion Nokia candybars to the latest Android smartphones to a whole host of embedded systems around the place and various webservers. They all use Java extensively and they never have an issue with the language.
Unfortunately there's a particular Java plugin from Oracles version of the Java VM that insists on running every Java program your browser comes across. You wouldn't run a plugin that runs every compiled executable you come across would you? Well Oracles Java plugin tries to run every Java applet it comes across. That's where these security flaws you hear about come from.
So Java as a whole is having its name tainted by one particular plugin.
Re:The important bit (Score:5, Insightful)
You wouldn't run a plugin that runs every compiled executable you come across would you?
Sadly, I have Flash installed. I think its track record is almost as awesome.
Re: (Score:3, Informative)
No, the vulnerabilities are in Java, not the plug-in. (In Oracles JVM, the Android JVM will have its own, disjoint set of vulnerabilities).
It's just most places Java runs don't have an exposed surface to attack. Server-side Java has had tons of vulnerabilities patched so far - but it was rarely urgent to apply the patches, since there's no access to that JVM from off the box.
The browser plug-in was the way the JVM flaws were eposed, but it was the JVM that had the flaws (OK, the plug-in also has its own s
Re:The important bit (Score:5, Insightful)
Well you can't say Java has flaws and then detail one particular set of flaws in one product. Even then your claims that the flaw is in the JVM is doubtful. I can right now load up a Java program in Oracles JVM and delete my files off my hard drive. I can also straight up spin up 100000 busy threads and bring my machine to a crawl. Are these flaws? Of course not. I can do the same thing in C++.
The flaw is allowing the browser plug-in to do things it shouldn't. The JVM itself is supposed to allow you full functionality including the ability to shoot yourself in the foot. The flaw is the fact you've exposed the JVM to the outside world. The Applet Plug-in tries to limit this functionality but fails. That is not the fault of the JVM.
Re:The important bit (Score:5, Informative)
Let me try to explain it:
Java (The language and vm) does in general allow code to do anything. Mess up the system, call native methods and so on. In this it is no different from other languages such as c++ and php, which is why no one are running c++ og php directly in a browser*.
But sun wanted to be able to run Java code in the browser, so they made an security manager, which in principle allow you to specify exactly what parts of the java standard library a program should have access to. So you can restrict file access, to specific sub directories. Control thread and process control, class loading and so on.
So each call to a potential dangerous method first goes to the system manager to ask for permission, and if permission is granted the rest of the method is executed. And here is part of the problem: Default for all methods is access granted if there is no call to the security manager.
So for every method in the Java library, they had to determine if it could me misused, and it it could be misused, they had to insert call to the security manager to verify that the user have access to use this method in this way based on the arguments to the method.
And just one method which don't verify its argument as good as it should is enough to grant access.
The problem is made far worse by the combination of the java class loader which loads classes dynamicly, and the java reflection api which allows dynamic class loading and method calling. Verifying that code can't use the reflection and class loader to bypass the security system is really difficult, as proved by the many security problems.
So when people say the problem is in the java browser plugin, they are not exactly right. The problems are in the java security manager, but I think the browser plugin is the only component which uses the security manager. Our server code for example don't need a security manager to control exactly what our code have access to, because the code is written by guys we trust, and the rest of the security is handled by the system.
*Or at least should not. Active X is Microsofts version of the "Try to run untrusted general purpose code in the browser project". And its security record is as bad as javas.
Re: (Score:3)
Well, you got a +5 :) but your assumptions about a security manager works and how amd where it is used: are completely wrong.
It is trivial to write a Java Application thatbuses a security manager and thus, e.g. restricting it from accessing the internet or certain parts of the file system.
Your idea that dangerous methods call the security manager is completely wrong. The VM calls the security manager before said method is executed.
Your assumption that the VM inserts the security manager code is wrong. See, for instance, the source code for java.io.FileInputStream(File) [grepcode.com]. You can clearly see starting at line 128 and continuing to line 131 that this check is performed by the library, not the VM. Similar code is present throughout the Java standard library.
Re: (Score:2)
Apparently something about the one makes the other absolutely impossible to fix. That, or Oracle simply doesnt care.
Either way, "a JRE plugin that wont ruin your network security" might be the most substantial feature ever, if they could hit it. Its all well and good to add new features to the language unless IT security everywhere are working on phasing out java (the client bits) because of its abysmal record...
Re: (Score:2)
And these features need to be supported in the JVM, creating a larger attack surface.
I'd think that deficiencies in intermediate forms can be handled. That aside, you can add as much syntactic sugar as you wish without compromising anything. (Well, the sanity of the developers, sometimes, I guess. :))
Re: (Score:2)
And these features need to be supported in the JVM
As far as I can tell, none of these features have anything to do with the JVM. They're all library and compiler changes. None of them are directly related to security or sand-boxing. It also seems like there will be no significant changes to class verification either. Only to allow annotations in more places, maybe lambas, but I dare say they'll be implemented as regular anonymous classes by the compiler.
Re: (Score:2)
Why do you think IBM built SWT?
Re:The important bit (Score:5, Insightful)
Actually, once you get used to Swing it is pretty hard to go back to any other toolkit. Swing is amazingly powerful, and ever since Java 1.6.0u10 also very performant (since it is based on Java2D which is DirectX accelerated on Windows and OpenGL accelerated everywhere else). One thing you do have to be aware of with Swing is not to block the "Event Dispatch Thread". Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'.
With the Nimbus Look & Feel the look of Swing is pretty awesome. Of course, many Swing developers have or are transitioning to Swing;'s successor, JavaFX 2. JavaFX 2 looks amazing (lots of special effects, gradients, transparency, reflections, animations etc that can be switched on very easily). JavaFX 2 does have a slightly different model for properties than Swing, so there is a bit of an impedance mismatch when you embed Swing into a JavaFX 2 UI or vice versa.
I understand many don't like the learning curve of Swing, and some of the overheads (eg. TableModels) - but it turns out these abstractions are necessary for users to be able to make custom controls (which is easier, IMHO, than other toolkits as you get a lot of control on how your custom will work exactly how you want it to).
The best thing about Swing, IMHO is not even the enormous capability for extensions. For me the best features is not only to have pixel-precise layout, but also you can make the UI resize *exactly* the way you want. While I like GWT and CSV for web stuff when I use them I always miss Swing as the later us able to work out the correct size of controls itself, and resizes exactly the way I want it (that's due to a problem in browsers computing layout [which the GWT guys called "intractable" in the browser; but Swing shows this is not the case on the desktop]).
There is a lot of life left in Java desktop technologies. I'm having a great time using OpenGL (via JoGL) in Swing to produce a modern jet combat flight sim. The ability to mix Java controls and 3D saves a lot of work (most 3D apps have to implement UI controls themselves - so end up behaving non-conventionally and looking a little odd).
Re: (Score:3)
Once you learn that, and how to use GrdiBagLayout properly then you are 'away laughing'
heh ... laughing from insanity? I think this sums up my experience with Gridbag [madbean.com]. I ended up switching to Mig Layout [miglayout.com] which was a paradise compare to Gridbag. It actually made Swing work fun.
Re: (Score:2)
Cool. Thanks for the tip on MigLayout. If I can't ever get GridBagLayout to work for me I'll definitely take a look at MigLayout.
Funny video. I guess changing things at random is what most GUI coders do, right? That's not my workflow - but I can see how GBL would suck until you learn all the aspects that make a layout work and resize properly.
At least you seem to be in the camp that Java on the desktop still has some uses :)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I once built a large rich UI client in Swing, once you embrace GridBagLayout it all works really well.
Swing just has a steep learning curve, and (at least at the time) kind of ugly controls. But it's very functional and not difficult once you understand the system.
Re:The important bit (Score:5, Funny)
I say we start a pool on how many zero days will be availible by the time it launches or even if we want to be generous, within the first week.
I will start it off with 7
Re: (Score:2)
An even more fun game is taking a stab at what Java version your computer has updated to at any one time. I thought I was on JRE 7u12, but I checked and we were up to u17 after a week.
You could probably make a pretty decent calendar out of JRE versions; year = 2006 + $MajorVersion, Week = $updateLevel.
Re: (Score:3)
Probably. Server side Java (where it is used mainly) is pretty much reasonable security wise.
Why would anyone enable Java in a browser is beyond me.
Re: (Score:2)
Probably. Server side Java (where it is used mainly) is pretty much reasonable security wise.
No, most of the Java security flaws apply to server side Java as well. It's just that you usually don't care, because an attacker has no way to exploit the JVM unless he's already running arbitrary code on the box.
Why would anyone enable Java in a browser is beyond me.
Remember all those crappy intranet apps that used to require IE6 and ActiveX? Many were replaced by crappy intranet apps that require Java in the browser. Same stupid, different toolset.
Re: (Score:2)
Summaries: I like them. Even such as we get around here.
Re:LOL Java (Score:4, Informative)
For non trivial programs Java does not use more memory than an equivalent C++ program.
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Re:LOL Java (Score:4)
For non trivial programs Java does not use more memory than an equivalent C++ program.
Only if the large majority of your data is in non-object arrays, or in very large objects so that the headers and overhead are small enough.
Re: (Score:2)
C++ objects also have an header/overhead. Where do you think the VTAB (virtual function table) is referenced?
With more I mean ofc significantly more. If I have a million objects and each of them has 4 extra bytes, that is 4 mega byte ... not much imho.
Re: (Score:3)
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
After all: it gets compiled down to the same machine code ...
Not exactly. Java is unable to vectorize floating point operations now (might change with java8 though), which is very common in any multimedia application. So it remains a lot slower than what you get by default in C/C++ with a decent compiler.
Re: (Score:3)
C++ is unable to perform comprehensive escape analysis (good for optimising multi-threaded code). C++ also lacks the ability to optimise virtual method calls.
Java can inline non-final methods and undo it if required.
There is a *lot* of stuff you can do when you have runtime optimisations as well as compile time.
You're technically correct in the Java is not compiled to machine code. The JVM does the bytecode to machine code compilation.
Re: (Score:2)
You're technically correct in the Java is not compiled to machine code. The JVM does the bytecode to machine code compilation.
That's like saying that it wasn't me who wrote this sentence, but instead I caused my fingers to move with the power of my will and my fingers wrote it instead. Java *is* compiled to native code. The last time I checked, the present simple tense was used for statements with general validity, and the general truth is that the majority of installed Java runtimes on PCs run the majority of opcodes executed *after* compiling them to native code. I don't see how you can make a more general statement than that.
Re: (Score:2)
Java is *not* compiled to native code unless the JVM decides it should be.Not all byte codes are compiled, it is faster to run it as interpreted code if you're only going to run the code a few times.
Also, not all JVM's have a JIT compiler.
Most bytecode is not compiled since it is not run frequently. Why do you think the JIT compiler is called HotSpot? It compiles hot spots of code in to machine code.
The code also isn't necessarily compiled in the same thread that the code runs it. A larger large loop will p
Re: (Score:2)
Java does not use more memory than an equivalent C++ program.
In an exclusively garbage-collected language with no deterministic finalization, it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed, in Java.
After all: it gets compiled down to the same machine code
But you still have to keep the bytecode and the VM in memory at all times, which hurts especially on a mobile device.
Re: (Score:2)
it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed,
Like allocating and deallocating the c_buff buffer each time a "std:string" gets created on the stack? And you think this is fast?
After all: it gets compiled down to the same machine code
But you still have to keep the bytecode and the VM in memory at all times, which hurts especially on a mobile device.
I doubt that APK (that is: an Android Package, not the hosts-file dead-horse) requires more than one JIT compilation (which is cached afterwards) and the GC in memory.
Re: (Score:2)
{
std::string aux="Dummy message: ";
aux=aux+" hello buddy";
std::cout << aux.c_str() << std::endln;
}
and see how RAII goes.
Re: (Score:3)
You don't need to wait till an object is garbage collected for non-memory resources to be closed. You call the close method (in a finally block, or use the try-with-resources introduced in Java 7)
The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.
If keeping bytecode in memory was really a deal breaker, there is nothing stopping the use of memory mapped files.
Destructor once and only once (Score:2)
The C++ compiler doesn't manage resources entirely for you. You need to do that yourself in your destructor.
The destructor needs to be written once and only once [c2.com], and for an object not created with new, the destructor automatically gets called once the object falls out of scope. In Java, you have to remember to finally { something.close() } or to try-with-resource every single time. Python is somewhere in the middle on this: because CPython's garbage collection uses reference counting, destructors get called automatically for anything that isn't held by a cyclic data structure, but Python also has with that acts
Re: (Score:2)
and every object you create with new must be explicitly deleted or you'll not only leak all the memory, you'll also never release the resources.
Re: (Score:2)
In an exclusively garbage-collected language with no deterministic finalization, it isn't possible to do something like C++ RAII, where non-memory resources are closed as soon as an object is destroyed, in Java.
If only we had something like dynamic-wind to deallocate resource we don't need anymore in GC'd languages... Oh, wait, we do!
Re: (Score:2)
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
That's funny since those contrived benchmarks are the only ones Java can actually win. Usually because the C++ code is also set to no optimizations. If this were really true why are all the high-performance multimedia, mathematics, etc. libraries all still written in C, C++ or Fortran? That's because Java is still magnitudes slower.
Re:LOL Java (Score:5, Interesting)
That's because Java is still magnitudes slower.
I'm afraid I have to disagree. I'm writing a modern jet combat simulator in Java and the runtime speed is fine. The bottleneck is never the CPU, it is always the GPU. I also have to say that Java's performance in terms of latency is very good. The reason for this is because I'm able to create a lot of threads very easily and Java manages resource sharing very well, plus use of the language features for synchronization threads and I get to use around 20% of each of the eight cores on my machine. When I use an excellent product in a similar niche called DCS:World I do notice that it's speed is somewhat hampered by the C++ running on a single core. Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.
So I think your comment is not correct. Java is comparable to C++ (sometimes faster, sometimes slower) on a single thread. When it comes to overall performance I find Java is faster overall because it is much easier to utilize all the cores in a machine with Java. In terms of gaming the performance of programming language used is nearly irrelevant - it is all down to how well you use the GPU (especially GPU memory; if you can keep stuff in VRAM then your performance is awesome).
Finally, let's move from the speed that is not that relevant (runtime) to the speed that actually matters (development time). Java is much much faster to develop in. You do have to spend some time profiling and tuning a Java program, but since you spend far far less time debugging than C++ you are still winning. I also love the JVisualVM that comes with the Sun/Oracle JDK and OpenJDK. While C++ has profilers they are a hassle to use, you have to compile your program each time you want to profile and recompile to measure different metrics. With JVisualVM you can profile any Java program without source and without recompilation since the monitors are built into the JVM (in exactly the same way as performance counters are built into operating systems these days, accessible by dtrace, strace, truss etc).
So, I think C++ is best used in niche programs where the host environment measures its memory in kilobytes. For other applications Java is more than fast enough on a single thread, has better throughput on multi-core machines, and is *much* faster to develop in (saves money, and also means something gets delivered sooner, as in, "faster time to market"). That's why Java kicks ass on the Tiobe Index - even if users only know about it from Minecraft and browser plugin issues.
Re: (Score:2)
I've used both, and I find it much easier to manage threads on C++ than Java. They both offer thread management, it's just a matter of what libraries you're used to.
Similar to "what language is faster to develop in". The language you know well is faster. I spend far less time debugging in C++ (and no time at all chasing leaks, thanks to RAII and Scoped Objects), and much less time worrying about resource management. Once again, because of what tools I'm familiar with.
The one place where C++ is just stru
Re: (Score:2)
I've used both, and I find it much easier to manage threads on C++ than Java.
Same here. Too many people extrapolate their own subjective experiences in using different languages as if they were a universally shared thing. Hell I know plenty of Python and Ruby programmers who find Java to be far less productive in their work.
Re: (Score:2)
When first reading your comment I though wtf?! After the second time I knew it must be sarcasm.
Re: (Score:2, Interesting)
I'm afraid I have to disagree.
And yet your anecdote doesn't really answer my question. If Java was so fast why do all the high performance libraries for things like multimedia not use it? Even the multimedia classes in Java's own stabdard library use native code libraries under the covers because pure Java would be too slow.
Now yes, multi-threading in C++ is of course possible, but it is much tricker than Java, especially the resource management.
I write multithreaded C++ code with Qt all the time. It is absolutely trivial. What is supposed to be tricky?
Re: (Score:3)
If Java was so fast why do all the high performance libraries for things like multimedia not use it?
There are pure Java codecs. They work fine. It is not the C++ that is necessarily fast, but the inline assembler you can put in. In fact, the perfect analogy of using native libraries in Java is when C++ is too slow and you use inline assembler. In both cases you use a higher level abstraction for the huge productivity boost and switch to the lower level abstraction only when you really have to (which is become more and more rare these days) - when you are prepared to sacrifice portability for performance (
Re: (Score:3)
When people talk about benchmarks in terms of faster they mean performance not development. In terms of development time, Java gets crushed by much higher level languages. As for projects that aren't CPU constrained but constrained by something else, you are just saying you don't care about performance. That's wholly different than Java having C like performance.
As for multithreaded, C++ is obviously faster. If you want non tricky multithreaded languages like Haskell or Eiffel crush both of them.
And no
Re: (Score:3)
Bro, your 1.5-5x is just not true unless the Java was written by idiots (and as we old timers remember the chestnut, "You can write bad FORTRAN in any language"). Even in 2008 Java was beating C++ and approaching FORTRAN for speed, citation follows. Now you can cherry pick whatever benchmark you want and it will show C++ as faster, and I'll choose another benchmark and that will show Java as faster. That means they are about on par with regard to performance (that wasn't true in the past, but is true toda
Re: (Score:2)
Of the top of my head:
Re: (Score:2)
* Java's GUI toolkit (swing) allocates memory all over the place meaning all the hard work you put into a no-allocation loop in your code is wasted when using a JTabbedPane allocates massive amounts of memory just by moving your mouse over it.
This is true if you are dealing with smartphones. In that case GCJ is an alternative, or C++. However, it is hard to find a *current* system that is so memory limited that this is an issue.
* Related to the point above - in code with strict scheduling deadlines, you can't use dynamic memory allocation (this goes for C++ as well as Java), but using any of the standard Java libraries and/or objects allocates memory all over the place. You can use things like the Javolution collections to get around these issues.
Multimedia is soft realtime. You simply spend memory to read ahead. If you are talking about controlling stepping motors in software (which I've done in the past), then it is a problem. If you are controlling stepping motor device driver hardware then it is not a problem. Sorry, I just can't see a case where you need a h
Re: (Score:2)
Unnecessary memory allocations increase the cache pressure on the CPU introducing extra memory stalls and forcing the VM to interrupt threads.
Re: (Score:2)
Same for speed. Unless you have a brain dead "repeat 1000 times" benchmark, Java is as fast as any other language.
Based on what? Java is rather fast but I have to see any other area of performance where it exceeds C/C++ and quite a few it is well slower than C/C++. The way it handles code is too similar. So by what metric is it "just as fast"?
And no it doesn't get compiled down to the same machine code. Abstraction adds complexity in machine code. That's why Fortran, C and Assembly consistently outpe
Re: (Score:3)
Re: (Score:3)
> Has it stopped being an overly-verbose, memory-hogging, slow, insecure pain the ass?
FTFY
Sounds like you got screwed.
Re: (Score:2, Informative)
Get your head our of your ass. Java is one of the most widely used programming languages. Just because you don't notice it on your desktop doesn't mean it isn't used.
Re: (Score:2)
Re: (Score:2)
It used to be useful on the server side, but every month that goes by it falls further behind.
every major programming index shows java at the top. oops. i'll let you google for "programming index" and click on the links.
At this point, the only reason to use Java is because that's what you've always used.
another reason to stick with it is because you like money and having a job. even if java was declining, you'd have steady employment in that space for the rest of your life.
Re: (Score:2)
In December 1974, the lambda was officially declared the international symbol for gay and lesbian rights
Oh my, they got it wrong, Church wasn't gay, *Turing* was! They should have selected the infinite tape as their symbol!
Re: (Score:2)
In December 1974, the lambda was officially declared the international symbol for gay and lesbian rights
I don't care if NAMBLA or the KKK adopts the lambda as its official symbol, it's a damn useful programming construct.
it fits right in here with the slasdhot fanbois.
Projection is SUCH a painful thing to watch.
Re: (Score:2)
It's also painful to watch how long C# will have had lambda (and the handy list-processing constructs that lambda's so handy for!) before Java releases with it. I wasn't a fan of C# until I had to use Java professionally, but that really made me appreciate C#.
Re: (Score:2)
Why is it painful to replace a simple function call with a multi-line for loop to map a function over a list? Why is it painful that you can't even have List<int> in Java?
Re: (Score:2)
Re: (Score:3)
Apparently, these lambdas don't even form real closures, their free variables can only be final ones.
Re:Java has too many versions (Score:4, Informative)
How exactly does it screw with compatibility? Old code will still compile. Old compiled classes will still load.
They're adding new stuff. Nothing old is being changed or removed.
You don't *have* to re-write anything. If someone tells you so, its because they want to.
It only screws with IT departments because they fear change. They also seem to not want to install security updates either.
The only JVM upgrade problems I've experienced in the last 10 years was with legacy code written for IBM's 1.3 JVM because the developers at the time thought it was a good idea to refer to com.ibm classes.
Re: (Score:2)
IMO, there's no problem with adding language features, but there's a big problem in that new JVM versions aren't always safe to move to! (And you can't use the new language features without the new JVM, of course).
There have been JVM point releases with memory leaks, and with serious performance degradations, in oddball corner cases. If your software happened to live in one of those oddball corners, and you moved to the latest JVM without full regression testing, you were hating life.
So simply moving to a
Re: (Score:2, Informative)
They're adding new stuff. Nothing old is being changed or removed.
Oh, ok, we'll tell that to all the apps that broke with JRE > 1.4.2u9 (ie, Cisco ASA crap). Or the apps that broke with JRE >1.5. Or >1.6u9.
If you havent seen incompatibilities due to java upgrades, be thankful: it means that you havent seen much of java.
Re: (Score:2)
It means I haven't seen that much bad Java code.
Re: (Score:2)
My IT department is still running Java 6 update 5 from 2008. They're too scared to upgrade to any later update levels because no one is going to give them the money to regression test every piece of Java code we've got.
The only saving grace is there is no browser plugin installed.
There has been well over 200 security issues fixed since 2008. As a bonus there has been significant performance improvements.
Re: (Score:2)
Oh, and good luck with XP in 12 months time when there are no more security updates.
Re: (Score:2)
I don't see the risk if you don't install the browser plugin.
Java belongs on servers, not in browsers. (perhaps the occasional desktop software too)
Re: (Score:2)
Yeah, it's basically true... most of the major feature additions in the last couple releases really do seem to be to catch up to C# (and other, more dynamic scripting languages). C# as a language is great - it's major problem is being so tightly associated with .NET/Sliverlight/etc.
At least Java has one thing going for it - a highly responsive owner/maintainer that listens carefully to all complaints and patches security vulnerabilities almost instantly!
Re:So... (Score:5, Insightful)
Java has one feature that C# doesn't. This one feature makes up for all the nice-to-have little C# features. That one feature is "portability", not only of the language, but even more importantly, *all* the standard libraries. Mono goes some way to alleviating this but there are some significant libraries that Mono haven't developed and also state (according to their own pages) that they will never develop. I don't know if you have noticed it yet, but the Microsoft is just one platform in the World - and the number of platforms is burgeoning. Apart from a few platforms Java is locked out of deliberately (iOS, Xbox) Java runs pretty much whereever you need to be - with very very little porting necessary (eg. through judicious use of libraries, like JoGL,JOAL, JInput a jet combat simulator I'm developing runs not only with unmodified source on Windows+Mac+Linux+[and some tweaks for Android]; but actually runs without needing a recompile ! [I know it is not true for everyone, but for me, "Write Once, Run Anywhere" really works - even for a very complex multithreaded OpenGL/GLSL real-time application]).
I hope that sheds some light on why some of the Java devs still use it. The nice features of C# don't necessarily make up for Java's awesome portability of *all* its libraries.
Re: (Score:2)
Java has one feature that C# doesn't. This one feature makes up for all the nice-to-have little C# features. That one feature is "portability", not only of the language, but even more importantly, *all* the standard libraries.
Uh... yeah, I completely agree, and said so in my previous post in a lot fewer words ;) C# language = great. Platform = sucks.
[Though of course my maintainer comment was complete sarcasm... Oracle seems to be very good at buying companies with popular, often open source products and fucking them up.]
Re: (Score:2)
[Though of course my maintainer comment was complete sarcasm... Oracle seems to be very good at buying companies with popular, often open source products and fucking them up.]
but the language is progressing nicely. java 8 has a lot of cool, requested features.
Re: (Score:2)
Re: (Score:2)
Definitely, and that's a great thing. Though Oracle still has a lot of control over the language - and suing Google for Android wasn't an encouraging move...
Re: (Score:2)
and suing Google for Android wasn't an encouraging move...
Fortunately the suit is over and Oracle pretty much learned their lesson. OpenJDK is safe to use and rely on (no vendor can kill it).
Re: (Score:3)
Not over yet, actually. If Oracle had really learned their lesson they wouldn't have appealed. I doubt they will win, but as I said it's still not an encouraging move.
But yeah, OpenJDK is not going anywhere, and the support behind it dwarfs even Google's resources...
Re: (Score:2)
The only platform that matters is the one your customers run. Portability matters so rarely in business it's almost a non-issue. Now, skills-portability is a different matter, but unfortunately while Java the language is learn-once-code-anywhere, actual Java coding is as much about what libraries/frameworks you've learned as anything else.
Re: (Score:2)
Then it's a good thing that all code everywhere is written for "customers" in a "business" environment, isn't it?
Well, it's a good approach to earning a living writing code. For a hobby, do whatever - sometimes doing it the hard way is the point of a hobby!
wrong - still supported and patched (Score:3)
Java 1.6 is the engine for java ee servers such as IBM websphere and tc server. there are still patches for 1.6 coming out, we just installed some at work recently for both the IBM and "Sun" (oracle) jdk
in fact, java 7 is optional add-on for websphree 8.5
Re: (Score:2)
should have added, that's only if you pay Oracle money. then you can get patches till 2016 from Oracle. For public patches for 6, you're SOL.
Re: (Score:2)
or similar stuff from Date::Manip in perl... so much more convinient to setup loops from "yesterday" to "last week"... as opposed to worring about actual dates, etc.