The Details of Oracle's JDK 7 and 8 'Plan B' 204
gkunene writes "Oracle has put Java 7 and 8 features up for Java Community approval, providing a clear indication of what the next two major versions of Java are likely to include. (Java 7 contents, Java 8 contents.) From the article: 'The JDK 7 and 8 JSRs represent Oracle's 'Plan B' approach for separating JDK 7 into two separate releases, splitting up features that were all originally intended for the Java 7 release. This approach is intended to help expedite new Java releases. Among the key components of the original Java 7 plan that are now set for inclusion in Java 8 are the Lambda and Jigsaw efforts. At JavaOne this year, Thomas Kurian, executive vice president, Oracle Product Development, explained that Lambda is all about bringing closures to the Java language. Kurian noted at the time that Lambda is intended to provide a more concise replacement for inner classes, as well as support automatically parallel operations on collections. Jigsaw is all about building modularity into the Java Virtual Machine.'"
Java Community approval (Score:4, Insightful)
Re: (Score:2)
Is now a bad time to be considering learning Java at UNI?
Re: (Score:2, Interesting)
The language you'll learn at uni isn't generally to learn the language - the language is used to deliver programming concepts. The language is rather irrelevant - although you'll probably be inclined to find a job that uses the programming language you've learned. Search around and find a different language you like (possibly also OO if you're just starting out) and do your stuff in java for uni, and then try and do it again in the language of your choice.
Java at uni is just the train. But considering your
Re: (Score:2, Insightful)
No. Learn as many languages as you can. You're less likely to believe that one language fits all needs that way. Java isn't going to suddenly drop out of use, there is too much investment in it.
Re: (Score:2)
The Java community consists of Oracle (databases), IBM (mainframes) and Apache (tomcat), like it has done for a few years now. You can't alienate the Oracle and IBM people, because they're paid to be loyal (i.e. they're employees at banks and stuff). The only people it alienated, are the tomcat people but then again, they are the only ones that truly benefit from java's one and only killer-feature, and that is that is runs anywhere.
Re: (Score:2)
There was a study, which was previously reported here, which stated, the vast, vast majority of Java applications never run on any system other than like-systems to which they are developed on and for. So basically, Java's run anyways promise never matters in the real world.
So chances are, if you're developing for a Win system, it will run on a Win system. If you're developing on a Linux/Unix system, chances are it will run on a Linux/Unix system.
Re: (Score:2)
Java's promise is not that any application runs anywhere, just as C doesn't promise that every program can compile and then run anywhere.
In C, you can build cross platform applications that run on many systems with a recompile.
In Java, you can build cross plattform applications that run on many systems without a recompile.
In both cases, you must be careful to not use system specific features to be truly compatible.
Re: (Score:3, Interesting)
Well my experiance is developing on windows and linux. Testing on linux. Deploying on various different Sun boxes some sparc 8 and 9's and some T1000 and T2000. More recently the code was deployed on a series of intel based blades (installed by IBM) in a new data centre. So yes just being able to do that makes java work well.
Re: (Score:3, Insightful)
Yes I have pushed java to it's limits. It mostly works. There some nasty things that will get you but trivially avoidable. When you have to put it on various machines it does just work. HP/UX I have not yet encountered.
Matt
Re: (Score:2)
I want to know what problems you have had. I've not really had many. Some issues with devs not handling files properly. But everything else worked fine. IBM's jvm has caused some issues and a few with Suns jvm.
Matt
Re: (Score:2)
I work in a Java shop (apps in Tomcat) and we do precisely that: devs have Windows PCs, deployment is to assorted Solaris and Linux machines. With our next server refresh, it'll be: Windows PCs, Solaris dev chain (x86 and SPARC), Linux live servers.
So if devs do anything that isn't cross-platform, their stuff just doesn't work.
Re: (Score:2)
Our devs have Windows PCs but the internal dev chain is Solaris. This means that if they do stuff that isn't cross-platform, it just doesn't work. In practice, this works out well and is fine with everyone.
Solution: make a "test" server that is Unix (and is automatically updated from CruiseControl or whatever). Commits don't count until they work on the test server. Works for us.
Re:Java Community approval (Score:5, Informative)
That has been years since the Java community is largely working outside of Sun, now Oracle, guidance. Innovation in the java world happens in third party open source frameworks that are born, mature and even reach legacy level before they make it into the Java JDK. Look at dependency injection, ORM, alternative languages on the JDK, ...
Obviously with a new boss around, especially with one with more teeth than the apathetic Sun, there is some territorial pissing going on between the big players: Apache, JBoss, IBM, ... but the split of the JDK is not such instance.
Re: (Score:2)
"Java Vista" was my precise thought too. This split appears to be a desperate attempt not to have Java 7 fall down a hole.
We're currently on Java 5, which was EOLed last November. I wanted to go to Java 7, and our stuff all works on it, but ... it was supposed to be out around now.
So we're going with Java 6. Which may never be EOLed at this rate.
Re: (Score:2)
Is there still a Java Community left to approve this? I thought Oracle had managed to alienate them all over the past 6 months.
All the fuss I've seen was more along the lines of various "Java Community" members crying "oh no, Oracle!" and making a fuss rather than Oracle actually doing something worthy of such a response.
Now you get people on Slashdot asking strange questions like whether it's a bad time to learn Java, and someone else freaking out because of the Oracle logo on OpenOffice. It's all rather odd.
Re: (Score:2)
Are you living in a cave or something? There are pretty good reasons for everything you are hand waving away. Even a quick skim of the latest slashdot articles on the subjects would clue you in.
Re: (Score:2)
It's funny you claim I'm "hand waving" them away, as you are conveniently "hand waving" them into existence. If you had actual examples in mind, it's suspicious that you wouldn't mention at least one or two.
The only thing that even remotely comes to mind is Oracle suing Google for their proprietary Dalvik VM. This seems pretty similar to when Sun sued MS for their proprietary Java VM, so it's not like Oracle is taking things in a turn for the worst with regards to their Sun acquisition.
Really, as far as I c
Re: (Score:2)
Ironically most of my ex workmates that still work in a lot of enterprise places are happy that java is finally moving forward. There was indeed a consensus that Oracle can't be worse than Sun.
I know quite a few companies that have a very strong dislike of Sun with
Re: (Score:2)
sssh, you're ruining it for them.
see, this is just a move to show that Oracle are being friendly and nice to the community. The fact that said community no longer exists was supposed to be a secret.
Re: (Score:3, Interesting)
It's hilarious how clueless you and most of Slashdot are. At Google, we're actually writing more Java code than ever, and Python is slowly being phased out. Pretty much all of the big companies in the area are consolidated almost entirely on a mixture of C and either Java or .NET. Python and Ruby are basically relegated to simple CRUD web applications where performance doesn't matter and threading is inconsequential. While Java is a pretty bad language, Python and Ruby aren't anywhere near being able to
Re: (Score:2)
So you're consolidating everything on a language managed and (as they see it) owned by a company which is currently suing you for using that language in ways they don't like?
Perhaps not the best strategy, regardless of the technical merits (or not) of Java.
Re: (Score:2)
Yeah, right. Google suddenly decides to use Windows in their farm.
And no reference of Go?
The GIL is no problem if you use processes or green threads.
But if it's so much bet, why choose it for Google App Engine? Why work on unladden swallow?
Re: (Score:2)
Google suddenly decides to use Windows in their farm.
Or, you know, Mono. With all the brain damage of .NET, C# is still a pretty awesome language.
And no reference of Go?
Go was meant to be an alternative to C, not Java. In particular, it's not object-oriented, even if it has some similar features.
Re: (Score:2)
Re: (Score:2)
Carousel is a lie, there is no renewal!
It seems a little lean (Score:4, Interesting)
Both releases seem a little lean on features compared to Sun's release schedule. On the other hand, they're starting to run out of reasonable features to add to the language without turning it into a kitchen sink.
Re: (Score:2)
Why stop when the memory drain is already working? =D
Re: (Score:2)
Re: (Score:2)
Oh come on now, you write Java code, you can't be trusted with unsigned types...
Re: (Score:2)
Generics "killed" Java (well, was a huge mistake, though did not kill it).
Since then practically every new language has been "higher level". Designers noticed that generics solves trivial problems[1] with huge cost (code clarity, maintenance and education). Now they seem to be putting everything up lamdba calculus, logic programming and parentheses in. That leaves BNF to be integrated so that programmers can invent heir own favourite extension to the language.
[1] problems which are found in simplest unit te
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:2)
I think they ran out of 'reasonable features' a while ago. Java has been a huge pile of crud [cat-v.org] for some time now, and with stuff like the badly botched addition of generics (even Joshua Bloch admits nobody really understands the mess created by generics in Java), this are only going to get worse.
Wait... what? (Score:4, Funny)
Oracle owns Java now?
When did this happen?
Re: (Score:2)
Re:Wait... what? (Score:4, Funny)
They've probably bought the rock you're hiding under too!
Closures? (Score:2, Insightful)
I think the focus on closures is a fad. The concept has existed for decades, but suddenly if Java doesn't have them it's incomplete? Strangely, I don't think the lack of them has ever stopped a program of mine from working. So this seems like more of a pissing contest with C# than a feature anyone is really clamoring for.
Re: (Score:2)
Re:Closures? (Score:5, Informative)
The lack of objects hasn't ever stopped any C program from working, but its lack is what inspired C++. Similarly, Java's lack of closures is what inspired C#.
Way back in the '90s, MS wanted to enable developers to use Java to write Windows apps. The obvious way to write Windows apps is for objects (like windows and buttons) to have events (like "mouse move" and "key down") that other objects can listen for by giving the object a function to call when the event is raised. Java had no clean way to write event listeners for VB-style form designers, so MS modified their version of Java (J++) to have closures (so you can say "use this object's OnKeyDown method to handle the KeyDown event"). Since Sun decided to go with inner classes instead, they sued MS and made them stop shipping any Java at all.
As a result, MS needed to write their own Java-like language for VB-style form designer apps, and came up with C#. Obviously it has closures (which it calls "delegates"), but in version 1.0 they only closed over an object's member variables. In 2.0 they were able to be anonymous and close over local variables in a method, and in 3.0 they gained the convenient lambda syntactic sugar. Some have called Java's inner classes "syntactic vinegar" because they're so cumbersome to use compared to C#'s (and most other languages') closures.
C#'s extension methods and generics combined with type inferencing and lambdas make it very concise to write code to return a list sorted by its item's name like this: list.OrderBy(item => item.name)
It's not unreasonable for Java programmers to ask for a similar boost in their productivity.
dom
Re:Closures? (Score:5, Informative)
Closures and delegates are different things: delegates are constructs that forward the invocation to another function, and closures are function objects that have some state of the program bound to them so as that it should not have to be passed explicitly to the function.
Nitpicking, I know, but I think it's in important distinction.
Re: (Score:2, Insightful)
Way back in the '90s, MS wanted to enable developers to use Java to write Windows apps.
Really? I was around int the '90s and have no recollection of that.
As a result, MS needed to write their own Java-like language for VB-style form designer apps, and came up with C#.
Please, don't be naive. MS first tried to poison Java by proprietary API (the same tactics Google is using in Android). When they failed, they created a copy of Java, invented a "new" language which is for some reason unbelievable similar to Java + some nice features and started the "developers, developers, developers" mantra. They called .net "java killer" internally, BTW.
Java was and still is a major risk for Microsoft.
Re:Closures? (Score:4, Interesting)
Spoken like a true Blub programmer [paulgraham.com]. Trying to go from a programming language that has true lexical closures like Ruby to a language like Java which doesn't is extremely painful. You get used to being able to write code that uses higher-order functions (and hence closures) to get stuff done.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Any minute now someone is going to bring up Turing completeness and point out that in theory you could write any program in Brainfuck. And someone else is going to point out that closures in languages like C# are objects, just hidden behind some syntactic sugar. No, wait, I just did both myself.
The point is that for certain common patterns, such as event callbacks, a closure-like syntax is significantly more readable than a co
Elephant in the room? (Score:5, Insightful)
Re: (Score:2)
Fact is that most "mainstream" languages are often way behind (read decades) what we know in terms of R&D for programing and compiling.
Re:Elephant in the room? (Score:4, Interesting)
Please, no.
Reified generics at the JVM level has unintended consequences for other language implementations targeting the JVM.
Ola Bini has an excellent take on why it's best to keep reified generics out of the JVM.
http://olabini.com/blog/2010/07/questioning-the-reality-of-generics/ [olabini.com]
Re: (Score:3, Insightful)
He also observes that reified generics would probably make Java itself a better language, and would be useful for Scala too. Which between them account for practically everyone using the JVM in the real world. Is it really worth hurting the vast majority of people (and driving some of them to competing platforms), in order to benefit a handful of tiny niche products?
Why the fuck bother (Score:3, Insightful)
Just take this [scala-lang.org] call it Java 9 or some such, and fire the remaining Java compiler people. Keep the VM people. There, solved it for you Oracle.
Re: (Score:2)
Don't see why this is being modded as flamebait. This is the truth. All those "geniuses", all that fabled "community process" got its ass handed to it by a few PhDs who _really_ knew what they were doing.
Re:Why the fuck bother (Score:4, Insightful)
And who didn't have to deal with backward compatibility. Designing a language from scratch is a completely different problem from evolving one that's heavily used.
Re: (Score:2)
WTF are you talking about? Scala compiles into the SAME Java bytecode, and runs on the SAME JRE, at mostly the same speed.
Re: (Score:3, Insightful)
Sack the VM people too, at least those who decided that the implementation of generics should be through type erasure, in other words "type unsafety". Next, dismantle the whole community process (Whoever wants an open system please fork at this exit). If Oracle just puts its weight behind java, it could well be the needed injection it needs. Without the tools for parallelism, distributed computing and so on, java (both VM and language) will be a "mainframe" language.
C# shows what can be done if you have
Re: (Score:3, Insightful)
They reason they did implement generic with type erasure (Something they knew was not the best solution) was so you could compile your Java 1.5 code, and run it on a jdk1.4 stack which don't know anything about generics. (They did not want to update the bytecode format, and with that restriction, type erasure was the only solution). So it was more of a management choice.
Why sun thought this was a better solution, then updating the bytecode is something I don't understand.
Re: (Score:2)
But in the same release they also put in stuff that just wont run in 1.4. So much that libraries often come in 1.4 and 1.5 versions. So they might as well have gone the whole way and put in the whole generics. What you dont want to break is 1.4 code running on 1.5. But to make provisions for the other way around is limiting, if not downright retarded.
Re: (Score:3, Interesting)
No, it's not because of too much FP. It's because Scala has some really weird stuff in it, such as implicit parameters [scala-lang.org] (where values are conjured out of thin air if not explicitly provided).
Or, say, implicit type conversions [codecommit.com] for the left side operand of "." (receiver) - so in "a.b", if the type of "a" doesn't have member "b" in it, the compiler will look for all accessible conversions from "a" to something else which does have "b".
This kind of stuff means that you can be looking at one simple line of code,
Re: (Score:2)
A branch of the Scala IDE for eclipse shows when there's an implicit conversion by underlining the converted expression. I guess this feature will come to other editors soon enough. Also, to have this conversion, you must have imported it (or its package object). The predefined conversions in scala.Predef are doing what you'd expect them to do and aren't very dangerous (much less, than say, built-in automatic conversion in some dynamic languages).
Implicit parameters are just like dynamic default values. Not
Re: (Score:2)
Well, it's the same as with any other powerful feature that enables more concise code - it makes said code potentially harder to read, depending on how it's used. Scala just goes further there than many other languages.
For the record, I disagree with GGGPs claim that Scala is "not a maintainable language". I do understand where he was coming from, though, and hence my comment about why this isn't really about FP as such.
Subclassing Enums (Score:2)
Will subclassing enums make it into JDK 7? It's annoying to jump through hoops that aren't a good model of the work when making enums of commands that are in different groups of overall common functionality.
Still at 5 here (Score:2)
I'd never had anything to desire since 5. So for me 6, 7 and 8 mainly should be backwards compatible.
Re: (Score:3, Informative)
If you had to do J2EE developement prior to EJB3, you would appreciate annotations. Basically a lot of the stuff from XML files went to annotations.
Re: (Score:2)
If you had to do J2EE developement prior to EJB3, you would appreciate annotations. Basically a lot of the stuff from XML files went to annotations.
Right now I'm considering JPA for a project of mine. I'm not confined to anything by some architecture dept. so I can make up my own mind.
The main reason for JPA would be that I can "easily" hook up my application to "any" type of database. I will consider annotations but I will shun any vendor specific stuff in my class code and hence in the annotations. But I have yet to study the matter in detail.
For me there's also another reason to use legacy Java version. Some large/huge clients of mine tend to
Re: (Score:2)
Annotations have been introduced in Java 1.5, especially for making the JPA more simple. Now the cardinality of relationships* are in the class body, previously they were in XML files, which were hard to maintain consistently. I have never seen vendor specific stuff in annotations, they usually appear in external xml config files (separately from the config files required by the standard).
Developers really hated EJB 2.x, so I don't recommend going that far back (that would mean going back to 2005-2006).
* an
New versions of platforms is bad (Score:2)
We all seemed to learn this lesson over the years thanks to Microsoft. People waited in line for hours to get Windows 95. The enthusiasm was present though diminished with Windows NT 4 and other Win9X releases. The enthusiasm was completely absent from WindowsME and beyond. Windows XP was a surprise hit, but no one I knew waited in line for it.
The point here is that Oracle seems bent on the notion of upgrading and releasing more changes to Java. This would be a mistake. As people write applications for
Re: (Score:2)
There's no deal to block, Microsoft bought some IP, which doesn't require any approval, and Attachmate is buying Novell which has nothing to do with Microsoft.
Re: (Score:2)
They should really focus their efforts on the whole Microsoft-Novell buyout.
What buyout? MS bought some IP; and we don't even know what that IP is. What's is the specific issue you're concerned with?
Re: (Score:2)
What makes Java so special for this field ? Or is just existing software ? Or available services ?
Re: (Score:2)
Re: (Score:2)
.net is all that and a bag of chips (OK stale chips if you don't want to count mono)... so... what makes java so special
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2)
Re:One area in which I appreciate the Java's power (Score:4, Informative)
The JVM is fast as hell these days. This line about java being slow is old news and no longer true. I say this as someone who does not really like java and tries to avoid Oracle products whenever possible.
Re:One area in which I appreciate the Java's power (Score:5, Informative)
Whenever people talk about the JVM being fast, what they really mean is that it's fast when it's already running, and when one compares programs whose typical running time is much longer than all that extra overhead so that it can be amortized.
That's great as it goes, but it's no C++ when performance really matters.
Re: (Score:2, Insightful)
Java can never start as fast as C or C++, it cant be done. I needs to start all kind of housekeeping threads, and allocate different memory pools etc.
But it is true that in a theoretical reasoning that Java execution speed can be faster then C++, and thats cause the JIT may rearrange and optimize the bytecode during runtime, to take advantages of a specific hardware in a way that you may not do in C++.
More often It goes slower tho, cause we all know when we stop coding features in, its when the good cases g
Re: (Score:2)
Actually, both of these are implementation issues. There's nothing (other than sanity) stopping you from running C++ code inside an ActionScript VM, and then you get the painfully slow startup time, bloated memory usage, but get dynamic trace-based optimisation.
The rest is not quite so clear cut either. The dividing line between dynamic and static compilation is blurred by profile-driven optimisations. For example, I've written some LLVM optimisations for Objective-C that provide some of the type feed
Re: (Score:2)
On the other hand writing internationalized, cross platform c++ apps is a major pain in the ass. In Java you don't have worry about character encoding, true type font rendering libraries (I just spent in 2 days getting ftgl compile), gui libraries, networking (worrying about character encoding again), http, xml parsing (worrying about character encoding again), and they all play along nicely.
If you use xerces for xml parsing (25 MB), the Java overhead doesn't seem that bad.
Re:One area in which I appreciate the Java's power (Score:4, Informative)
Does that even matter? Java is most used in long-running programs, not programs that are starting many times a second. The startup cost is minuscule. Focusing on startup cost is as pointless as these reviews of linux distros that concentrate on how fast the distro boots. No one is sitting there rebooting over and over saying "look at how productive I am now."
Re: (Score:2)
If anything, Java is going to be slower than most native languages
Care to name some examples? Please spare me .NET and C#. These two never existed in the late 90s.
Firstly .Net is not a language and C# is not a native language. Secondly why does it matter that they didn't exist in the late 90s? And if you are stuck in the late 90s then you'd know back then native languages - C++, Smalltalk, etc... - were significantly faster than Java in almost all cases, the gap is not as broad anymore.
But im interested to know what it is about Java specifically that you think makes it superior for your purposes?
Re: (Score:2)
"Once its in bytecode it is native."
No, not unless you have something like Jazelle [wikipedia.org].
Re: (Score:2)
Re: (Score:2)
Smalltalk. I considered a job a while ago at a company that managed a trading platform written in Smalltalk (Cincom's dialect, I think, but it might have been IBM's). They picked it because it was the language that allowed them to modify their automated trading algorithms the fastest out of all of the ones that they tried.
Does Java yet have the ability to replace classes in running programs or perform incremental upgrades without stopping the program? These have been standard features in languages lik
Re: (Score:2)
Re: (Score:2)
He posts at 0 for a good reason, stop feeding the trolls.
Re: (Score:3, Funny)
You mean the emergency birth control pill? Well Java does feel like it was aborted these days.
Re: (Score:3, Insightful)
Considering COBOL still has a presence in the Enterprise world I really doubt Java will go away that fast. If they went maintenance only today, maybe in 10 years it would start to be phased out in the Enterprise and maybe gone in another 25 years.
Re: (Score:2)
That's STILL an aggressive timetable compared to COBOL, and COBOL was hardly as entrenched as java.
Re: (Score:2)
Isn't there a point where th language has enough features?
I think as new features are required in the development world, they're properly added to libraries. E.g., XML, RSS, ssh, XMLRPC, etc. libraries.
And if you want a language with the syntax-of-the-day, there plenty of languages running on the JVM.
Re:Go Java Go (Score:5, Informative)
For starters, to provide some context, here [java.net] is the current text of Project Lambda proposal - it's a fairly short and readable document explaining both syntax and semantics. Here [java.net] is the mailing list.
Project Lambda. The proposed syntax needs to be more Java-like.
There's a load of issues with semantics as well. They carried over a bunch of limitations from anonymous inner classes, such as inability to capture mutable locals (though at least you don't have to slap "final" on everything now, that will be inferred) - so it's still not true closures.
I was also rather disappointed by the way community input was handled in Project Lambda. Originally, it was unclear why they started it from scratch when there were as many as 3 major proposals for lambdas already (BCGA, CICE, FCM) which could be used as a base. The original claim was that community is too divided on those, and so a "clean slate" effort, guided by feedback of all interested parties, would reach a more universally accepted solution. What happened instead is that, after a lot of discussion on syntax and semantics, Sun - er, Oracle - just published their own spec and started to implement it right away. Pretty much all feedback on that was either quietly ignored, or disregarded under various reasons. This concerns both syntax and semantics.
With syntax it was especially disconcerting. Originally, there was a lot of discussion focusing on syntax on the mailing list, so Sun/Oracle folks declared a moratorium on it, saying that it's "not so important" and that "we can discuss it later", after semantics are figured out. Since then, their proposals have had a major unilateral revision of syntax, and that is seemingly final for the proposal given that it's what they plan to submit for JCP. So the syntax was effectively not discussed at all in any way that made a difference, even officially.
The only case of feedback on semantics seemingly making any difference was with respect to lexical scoping of identifiers in the lambda. Consider this code:
The question at hand was about what "this.foo" in the lambda body is supposed to mean. The original Sun/Oracle proposal wanted to have the same rules as for anonymous inner classes; in this case, since the lambda is an instance of SamType, this would mean resolving "foo" to SamType#foo on the lambda itself, and you had to write "this.Test.foo" to get the other one - again, same as with AICs. After a lot of negativity on the mailing list, they've changed it to use strictly lexical scoping - so "this.foo" now refers to Test#foo.
However, even in that case the attitude was interesting - when discussion started on the mailing list, Sun employees were quite dismissive of any criticism, and their response pretty much boiled down to "we believe users who're used to AICs will want lambdas to behave the same". Then suddenly they release a new spec with updated semantics, and no comments as to why they changed it, disregarding their own past arguments in favor of the old one.
So, as far as "community participation" goes, I'd say that Project Lambda has largely been a failure so far. We'll see if it favors any better in JCP.
As to its technical merits - we'll see when it gets released, but if this happens in its present shape, then I'm afraid that it is rather deficient to all competitors out there (Scala, C#...). Aside from capturing mutable locals, one other major issue that goes unresolved is that they had discarded first-class function types, so you have to make do with SAM ("single abstract method")
Re: (Score:2)
I for myself found current state of lambda proposal much better than any of the previous proposals
If you look carefully, I've linked to the very same document from my post. What, in particular, is special about the last part of that document?
In any case, my point is not that the present revision of the lambda proposal is worse than previous revisions from Sun/Oracle. My point is that it's worse than the third-party proposals that preceded it (especially BGGA [javac.info]). It's also worse than implementation of closures that is already present in other languages that directly compete with Java - most notably, in C#
Re: (Score:3, Interesting)
Macros in Lisp were introduced in the mid-1960s and are a powerful way to extend that language. However, the syntax of Lisp is very regular, so adapting the power of the prefix notation of Lisp into a language with a procedural syntax like Java is not going to be too easy.
I'm a little surprised that there isn't more mention of Lisp in this thread, considering that the lambda calculus that it was built on is the source of the name for one of the language projects.
Being able to transparently extend your langu
Re: (Score:2)
However, the syntax of Lisp is very regular, so adapting the power of the prefix notation of Lisp into a language with a procedural syntax like Java is not going to be too easy.
Seems that some people write a Lisp-like interpreter in Java and then have the "configuration files" aka programs in XML ;).
I've seen some pretty large XML config files...
Re:Go Java Go (Score:4, Interesting)
The funny thing about the great flexibility that the frameworks like Spring provide is that you are defining the functionality in the XML files instead of the code, but now you have to learn two languages. The nestable list structure of Lisp is almost the same as the hierarchical format of XML, and in fact, that is how they are often represented natively in Lisp XML parsers. Instead, you could just use one language, structure your data properly, and extend the language to fit your problem.
Re: (Score:2)
So everyone has to use a Turing-complete language for configuration files? How about IDE and tool integration which is impossible in general with Turing-complete languages?
And if we restrict ourselves to pure s-exprs, then we just get isomorphic representation of XML.
Re: (Score:3, Insightful)
For a growing complexity in a certain problem domain, the border between configuration and the creation of a domain specific language becomes rather thin.
Re: (Score:3, Insightful)
Re: (Score:2)
I think GP's point is perfectly valid: only use a stronger language, when absolutely needed. (In the Java world they're Groovy, JRuby, Jython, Beanshell) Macroing is nice, I've done a lot of it in Prolog, but for group project static checking can save a lot of pain in the ass.
Re: (Score:2)
This is nothing new. Well there is one thing new. The new Pirate is not bankrupt.
Re: (Score:2)
Ah, but there lies the evil of the IP salesman. It's nearly impossible to fork Java because of all of the patents that Oracle owns. See, if you fork it and aren't 100% compliant with their license (i.e. you want to do something useful that goes outside the spec), you violate their patents. If you violate their patents, you get sued.