Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
karianna
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
karianna
9y ago
This is actually a huge change for operations / devops. JFR is the only tooling out there today that can accurately and safely gather important performance metrics from the JVM in a low impact manner. All other APM vendors like ourse
62.
▲
by
karianna
9y ago
I sit on the standards body for Java EE which will be involved in helping make this step - would love to hear opinions on what foundation and licensing they'd like to see this under (and why ). Some Java EE specs are already at Eclips
63.
▲
by
karianna
9y ago
They are highly motivated by internal (Oracle cloud) and external factors (Oracle as A technology leader) factors as well as professional pride (core Java folks are ex Sun) so I'm personally highly confident
64.
▲
by
karianna
9y ago
Java EE 9 - so 2018 at the earliest
65.
▲
by
karianna
9y ago
Hi all, Martijn Verburg here - London Java Community (LJC) representative on the Java Community Process (JCP) Executive Committee (EC) (dear Cthulu, the acronyms) otherwise known as the Java standards body. Here's our reasoning for vot
66.
▲
by
karianna
9y ago
Hi all - interested in early access builds and / or helping out? Head to OpenJDK.java.net and join the Valhalla project and the Adoption Group. Disclaimer - I help run the adoption group and maintain the Valhalla wiki.
67.
▲
by
karianna
9y ago
I'll prefix this with "I'm not a language design or modularity design expert". I personally would have preferred that JPMS was treated as an internal JVM/API concern. This still would have meant changes for IDE and
68.
▲
by
karianna
9y ago
See http://mail.openjdk.java.net/pipermail/jpms-spec-experts/201... - I think this is a decent compromise and a majority of the Maven folsk seem to agree. We're hoping to take it for a test drive this Saturd
69.
▲
by
karianna
9y ago
Well I don't think even my nearest or dearest would call me adorable, but hey :-). The module system proposal did state that the user module system was a non goal, but the design of it means that it does impact existing user module
70.
▲
by
karianna
9y ago
Hi Mike, yep - you've found one of the relevant threads.
71.
▲
by
karianna
9y ago
This is correct and possibly seems crazy from some other language communities :-), but Java is fairly venerable (20 yrs) and is a backbone platform for many risk averse entities and this strong social contract has I believe added to its lon
72.
▲
by
karianna
9y ago
We have been in close contact with the developers throughout - we're the Java User Group that runs the Adopt a JSR and Adopt OpenJDK programmes that test these things out as early as we're able. The blog post details one of our
73.
▲
by
karianna
9y ago
No, there are still substantive issues on the table, we just expect that they'll be cleared up in the next 30 days. But since this is so deeply fundamental to the core platform we're only going to vote yes when we're really
74.
▲
by
karianna
9y ago
We believe that that the Java specification for a new module system does need to have an interoperability story with the package management system that Gradle/Maven provides. In particular, the module system needs to be able to bridge&
75.
▲
by
karianna
9y ago
Hi all, I'm the EC representative for the London Java community (~6000 Java developers, have lots of global outreach programmes etc) - here's our more detailed post on why we voted "No". https://londonjavacomm
76.
▲
by
karianna
10y ago
We're working on versions of Java, Nginx, MySQL etc that can run inside the secure enclaves, it's interesting and challenging work! http://www.serecaproject.eu/
77.
▲
by
karianna
10y ago
Disclaimer: I'm the CEO of jClarity who produces Censum. For those who are looking to read the arcane output of a Java GC log, you can grab a 7-day free trial of Censum ( https://www.jclarity.com/product/censum-free
78.
▲
JClarity, RedHat, London Imperial working on secure enclaves for cloud providers
(jclarity.com)
1 points
by
karianna
11y ago
|
0 comments
79.
▲
Incremental builds with Gradle
(gradle.org)
3 points
by
karianna
12y ago
|
0 comments
80.
▲
Hazelcast Announces Business Model: Open Source, Open Standards and Community
(blog.hazelcast.com)
2 points
by
karianna
12y ago
|
0 comments
81.
▲
Top testing tips for discriminating java developers
(zeroturnaround.com)
4 points
by
karianna
12y ago
|
0 comments
82.
▲
All for contributions to Snowcast, open source ID generator on Hazelcast
(blog.hazelcast.com)
4 points
by
karianna
12y ago
|
0 comments
83.
▲
Using Devops to Bootstrap Hazelcast in Minutes
(dbrimley.github.io)
6 points
by
karianna
12y ago
|
0 comments
84.
▲
Injecting dependencies for scalability with Hazelcast
(blog.hazelcast.com)
7 points
by
karianna
12y ago
|
0 comments
85.
▲
JavaOne: Hazelcast Announce JCache Support and JCP Run
(infoq.com)
7 points
by
karianna
12y ago
|
0 comments
86.
▲
by
karianna
12y ago
We helped test out the RI and TCK - it was in the end up built for Java EE in mind (that's not to say someone couldn't provide a stripped down version that could work for SE - but I don't think anyone has or will).
87.
▲
by
karianna
12y ago
There maybe some small ones, but the (and I think correct) decision was made to focus on the JVM for Java 9. Java 8 bought in enough language features to keep Joe/Jane Java developers happy (most bleeding edge folks moved to Scala or
88.
▲
by
karianna
12y ago
It will depend on howe small a profile the JVM language can run on. In theory you could run some JVM languages on the compact profile resulting in a n overall faster startup time.
89.
▲
by
karianna
12y ago
Likely delivery timeframe for value types in Java 10. Definitely not Java 9. Source - many conversations with Brian Goetz et al.
90.
▲
by
karianna
12y ago
I'd be cautious of a 2013 report. G1 has had significant work put into it over the past year and is much improved in its latest incarnations. We've seen best results with Java 8u5+ (Disclaimer: I run a company that sells a GC an
More ›