Oracle klar med Java 7

Java 7 is the release everybody has been waiting for, for quite a long time.

Windcape (2) skrev:

[...]
Nu kan de stakkels java udviklere få de features vi andre har haft i C# i 4-10 år.

Darwind (4) skrev:

4 - 10 år - det er sq bredt :O Hvilke features er det C# har som Java har manglet så meget?

Darwind (4) skrev:

Jeg håber da for satan ikke folk har ventet længe på syntatisk sukker

Windcape (5) skrev:

Det er jo ikke sukker at kunne gøre:

var adults = guests.Where(guest => guest.Age >= 18);

Alrekr (3) skrev:

Yay! Det passer lige med at jeg skal lære at programmere java til næste semester.....

sheph (6) skrev:

Så det bliver ikke oversat til en løkke der løber igennem listen af gæster? Det ligner sukker for mig. Men ganske praktisk sukker :-)

sheph (6) skrev:

Windcape (5) skrev:

Det er jo ikke sukker at kunne gøre:

var adults = guests.Where(guest => guest.Age >= 18);

Så det bliver ikke oversat til en løkke der løber igennem listen af gæster? Det ligner sukker for mig. Men ganske praktisk sukker :-)

Windcape (2) skrev:

Men eller ser det fint. Nu kan de stakkels java udviklere få de features vi andre har haft i C# i 4-10 år. Jeg er sikker på at selv myplacedk vil blive glad for at kunne bruge lambda expressions :p

Windcape (5) skrev:

Primært er det closures (.NET 1.0), optimal parameters (.NET 1.0, C# 3.0), og lambdas (.NET 3.5). Jeg har ikke styr på om Extension Methods (.NET 3.5) også kom med i Java 7, eller det først er Java 8.

Windcape (11) skrev:

ALT Java dokumentation fra java.com (be it docs or tutorials) ligner noget fra 90erne (hov vent, det ER fra 90erne).

Windcape (11) skrev:

og skrive javadocs et seriøst makeover!

Chucara (9) skrev:

Selvfølgelig er begge sprog turing komplette, og selvfølgelig kan man bruge 3. parts libraries, men ting som WPF, WCF, Entity Framework, Parallel Computing og LinQ gør bare livet lettere for en .Net programmør.

arne_v (12) skrev:

Lambda, optional parameters og extension methods er ikke med i Java 7.

arne_v (12) skrev:

Java docs har faktisk fået en større overhaling i Java 7.

Efter mere end fem år siden frigivelsen af den forrige version er Oracle nu klar med den næste store opdatering til Java SE, Java SE 7.

Opdateringen kommer efter en turbulent periode, hvor Java gik fra at være under Suns vinger til nu at være kontrolleret af Oracle. Netop dette faktum har mødt en del kritik og fik for ekempel Apache Foundation til at trække sig fra eksklusivkomiteen (EC) i JCP-samarbejdet (Java Community Process) tilbage i december 2010.

silashansen (16) skrev:

Det er ikke et spørgsmål om hvorvidt man, givet uendelig tid, kan opnå det samme resultat på en anden platform, det er et spørgsmål om hvor veludviklerede værktøjerne er, da tid ofte er lig penge.

arne_v (13) skrev:

Hvad laver du i WCF, EF og TPL som du ikke kan lave i de tilsvarende Java teknologier?

Alrekr (3) skrev:

Yay! Det passer lige med at jeg skal lære at programmere java til næste semester.....

Windcape (19) skrev:

Jeg synes ikke rigtigt at der er/har været noget tilsvarende til TPL i Java.

Windcape (19) skrev:

Fik de faktisk inkluderet Fork/Join i Java 7 ?

Windcape (19) skrev:

Derudover er biblioteker som TPL altså noget mere behageligt at bruge i sprog der har closures!

silashansen (15) skrev:

hvilket gør det endnu værre at Java7 ikke engang kan nå C# 3.5 til sokkeholderne.

arne_v (18) skrev:

Ja.

Men hvad er det indenfor de 3 emner som du mener tager længere tid i Java end i C#?

class Tarpit
public int fire(int->int fun)
return fun(0)

class Foo
private int x = 42
public blabla main(???)
Tarpit.fire(i => {
x+=random(10)
return x+1
})
println(x)

onetreehell (26) skrev:

@syntaktisk sukker
Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.

onetreehell (26) skrev:

Er det muligt at lave sådan noget her i C# eller java m. lambda expressions?

using System;

namespace E
{
public delegate int Fun(int v);
public class Tarpit
{
public static int Fire(Fun f)
{
return f(0);
}
}
public class Foo
{
private static int x = 42;
public static void Main(string[] args)
{
Tarpit.Fire(i => { x+=(new Random()).Next(10); return x+1; });
Console.WriteLine(x);
Console.ReadKey();
}
}
}

onetreehell (26) skrev:

Det med at det skal være sikkert har irriteret mig noget. Javas sikkerhedsmodel gør at man ikke umiddelbart kan have ægte tail calls i JVMen :/

using System;

class Tarpit
{
public static int Fire(Func<int, int> fun)
{
return fun(0);
}
}

class Program
{
private static int x = 42;

public static void Main()
{
Tarpit.Fire(i => {
x += (new Random()).Next(10);
return x + 1;
});

Console.WriteLine(x);
}
}

arne_v (24) skrev:

MS har også en lang tradition for at:
- flere features er godt
- tools er vigtige
- det skal være nemt for udviklerne

arne_v (24) skrev:

I Java verdenen er man mere blandede men traditionelt har der været synspunkter som:
- sproget skal være simpelt
- det skal være god OO
- det skal være sikkert
- det skal være portabelt

onetreehell (26) skrev:

Jeg kunne godt tænke mig at se hvad det er der i forvejen eksisterer i java som semantisk set er det samme som λ-udtryk.

onetreehell (26) skrev:

#12
Jeg skulle også lige til at skrive at λ-udtryk ikke er med i java 7.

28 July 2011 - WARNING: Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7

Oracle released Java 7 today. Unfortunately it contains hotspot compiler optimizations, which miscompile some loops. This can affect code of several Apache projects. Sometimes JVMs only crash, but in several cases, results calculated can be incorrect, leading to bugs in applications (see Hotspot bugs 7070134, 7044738, 7068051).

Apache Lucene Core and Apache Solr are two Apache projects, which are affected by these bugs, namely all versions released until today. Solr users with the default configuration will have Java crashing with SIGSEGV as soon as they start to index documents, as one affected part is the well-known Porter stemmer (see LUCENE-3335). Other loops in Lucene may be miscompiled, too, leading to index corruption (especially on Lucene trunk with pulsing codec; other loops may be affected, too - LUCENE-3346).

These problems were detected only 5 days before the official Java 7 release, so Oracle had no time to fix those bugs, affecting also many more applications. In response to our questions, they proposed to include the fixes into service release u2 (eventually into service release u1, see this mail). This means you cannot use Apache Lucene/Solr with Java 7 releases before Update 2! If you do, please don't open bug reports, it is not the committers' fault! At least disable loop optimizations using the -XX:-UseLoopPredicate JVM option to not risk index corruptions.

Please note: Also Java 6 users are affected, if they use one of those JVM options, which are not enabled by default: -XX:+OptimizeStringConcat or -XX:+AggressiveOpts.

Windcape (29) skrev:

arne_v, dit C# er lidt rusten ;-)

Windcape (19) skrev:

F.eks. som dette her ville være svært at efterligne i Java. (At C# 5.0 async så gør det obsolete, er noget helt andet)

this.button1.Click += new System.EventHandler(this.Button1Click);
...
void Button1Click(object sender, EventArgs e)
{
var webRequest = WebRequest.Create("http://www.reedcopsey.com");
webRequest.GetReponseAsync().ContinueWith(t =>
{
using (var sr = new StreamReader(t.Result.GetResponseStream()))
{
string str = sr.ReadLine();;
this.textBox1.Text = string.Format("Page at {0} supports XHTML 1.0: {1}", t.Result.ResponseUri, str.Contains("XHTML 1.0"));
}
}, TaskScheduler.FromCurrentSynchronizationContext());
}
...
public static class WebRequestExtensions
{
public static Task<WebResponse> GetReponseAsync(this WebRequest request)
{
return Task.Factory.FromAsync<WebResponse>(
request.BeginGetResponse,
request.EndGetResponse,
null);
}
}

final ExecutorService es = Executors.newFixedThreadPool(2);
btn.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
try {
final URL url = new URL("http://www.reedcopsey.com");
es.submit(new Callable<Void>() {
public Void call() throws Exception {
BufferedReader br = new BufferedReader(new InputStreamReader(url.openConnection().getInputStream()));
final String str = br.readLine();;
EventQueue.invokeLater(new Runnable() {
public void run() {
tf.setText(String.format("Page at %0$s supports XHTML 1.0: %1$b", url, str.contains("XHTML 1.0")));
}
});
br.close();
return null;
}
});
} catch (MalformedURLException ex) {
ex.printStackTrace();
}

}
});

arne_v (34) skrev:

Men Func<> og Action<> har aldrig været min kop te. De er simpelthen ikke typesikre nok.

Windcape (11) skrev:

#10
Og hele ideen med at f.eks. Eclipse skal parse (invalid) HTML for at kunne tilbyde intellisense er *scary*

Windcape (36) skrev:

Err, hvordan kan de ikke være typesikre nok?

Windcape (11) skrev:

Og hele ideen med at f.eks. Eclipse skal parse (invalid) HTML for at kunne tilbyde intellisense er *scary*

Windcape (11) skrev:

De kunne godt tage sig sammen og begynde at lave noget XML dokumentation, ligesom .NET.

Windcape (38) skrev:

The pinnacle of hippie development. Using broken HTML for what XML is made for.

onetreehell (39) skrev:

Det har altid irriteret mig meget. Det er svært at søge i dokumentationen, det kræver en browser og så er der de forbandede frames! Og så er det også træls at skrive værktøjer til for så skal man til at scrape html

arne_v (41) skrev:

Formålet med JavaDoc er at lave dokumentation for mennesker.

Til det formål er HTML bedre end XML.

arne_v (41) skrev:

Til det formål er HTML bedre end XML.

silashansen (42) skrev:

Et standardiseret dokumentations xml format + xsl til "menneskevisningen" ville imo have været den sublime løsning.

Windcape (43) skrev:

"var", ikke "er".

Windcape (43) skrev:

Du kan også lave MSDN-like dokumentations sider ud fra de XML filer som Visual Studio laver.

arne_v (45) skrev:

Virkeligt.

Hvilket software producent foretrækker XML over HTML til brugerne?

Windcape (47) skrev:

Pointen er at du kan lave XSLT stylesheets i dag,

Windcape (47) skrev:

Og *alle* browserne kan forstå XSLT stylesheets i dag, du skal ikke engang bruge serverside manipulation mere!

Windcape (47) skrev:

hvilket gør det direkte idiotisk at autogenere HTML frem for XML.

WinPower (49) skrev:

Desuden er det totalt irellevant at Java kan køre 100% ens på Windows, Linux og Mac.