Tag: java

Posted on

Oracle have something to announce re. Java EE 8 at JavaOne this year?

Oracle have been quiet on the Java EE front since around November 2015 according to public minutes from recent JCP Executive Committee meetings,  which has led to the forming of the Java EE Guardians group forming to rally community awareness and promote the future of Java EE.

This story on The Register just popped up in my feed this evening, with an interesting quote from ‘Oracle spokesman’ Mike Moeller, stating:

“Oracle is committed to Java and has a very well defined proposal for the next version of the Java EE specification – Java EE 8 – that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the Cloud … Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September.”

So there you go. Given that there is already an EE8 JSR in flight (JSR 366) encompassing many other JSRs that were planned to be included in EE8, this statement sounds suspiciously like Oracle has “something else” planned for EE8 that is not the EE8 JSR (“a very well defined proposal for the next version of the Java EE specification”).

In a thread on the Java EE Guardians Google Group, seems like no-one over there has any other insight into this news at this point.

Interestingly, microservices, large-scale distributed computing and containers… this is all very much on target for where EE needs to be heading.

If this is all Oracle is willing (or able) to share at this point, then it will definitely be interesting to hear what they have to share at this year’s JavaOne conference.

Posted on

MongoDB Java api: using a sequence collection with findAndModify()

MongoDB doesn’t have an equivalent of sequences typically used in relational databases, since documents are automatically given a unique ObjectId value for the “_id” property when inserted.

To return data from documents via a REST api, it may be more useful to use a sequential unique key. The MongoDB docs have an example of how you could use a Collection to hold a document per sequence that you need, and increment a value property each time you retrieve it with findAndModify().

There’s a number of questions on StackOverflow related to this approach, most seem related to the approach doc linked above (e.g. here, here, and articles elsewhere, like here).

To implement this approach using the Java api, using findAndModify() seems to be key, as you need to ensure you are querying and incrementing the sequence value in a document in a single, atomic step. After that point once you have the updated/next value from your document holding your sequence, the fact that you use that value in a subsequent atomic insert to another document seems to be safe (please leave me a comment if this assumption is not correct!), as every call to findAndModify() to increment the sequence value is atomic (making an assumption here based on my limited MongoDB knowledge, but I think this is correct!).

Here’s how I implemented the approach using the Java api:

[code]
public int getNextSequence() throws Exception {
DB db = MongoConnection.getMongoDB();

DBCollection sequences = db.getCollection("sequences");

// fields to return
DBObject fields = BasicDBObjectBuilder.start()
.append("_id", 1)
.append("value", 1).get();

DBObject result = sequences.findAndModify(
new BasicDBObject("_id", "addressId"), //query
fields, // what fields to return
null, // no sorting
false, //we don’t remove selected document
new BasicDBObject("$inc", new BasicDBObject("value", 1)), //increment value
true, //true = return modified document
true); //true = upsert, insert if no matching document

return (int)result.get("value");
}
[/code]

 

Posted on

The future of Java EE as discussed at recent JCP Executive Committee meetings

If you’ve been following Java EE related news over the past few months, you’ll know that Oracle cut back on a number of its Java Evangelist employees, others such as Reza Rahman appear to have left of their own accord, and there’s a general concern than Oracle appears to have slowed down input on any Java EE JSR. Rahman has formed a group called the Java EE Guardians to drive community activity to support future development of Java EE and EE JSRs.

If you want more of an inside view to what’s going on, there’s some interesting reading in the form of the JCP Executive Committee meeting minutes which are public record. The minutes for June 2016 and May 2016 both had agenda items to discuss the future of Java EE. The minutes from the May meeting are very interesting, including comments such as :

“…concern that Oracle, despite its role as steward of Java, has not made any public statements or explanations for the apparent lack of activity on Java EE”

and recording of a statement to Oracle from the JCP Executive Committee formally voicing their concern:

“EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.”

Other concern recorded in the minutes was that Oracle holds IP rights for the majority of the JSRs that are in progress, and so passing responsibility on to other parties requires Oracle’s involvement to pass on ownership of this IP… something which they may agree to, or may not.

Minutes from April 2016 note:

“Martijn Verburg reported on behalf of the London Java Community that it now seems clear that little if any progress is being made on Oracle-led Java EE JSRs. (Some Oracle Spec Leads have admitted publicly that they are unable to spend any time on their JSRs, having been directed to work elsewhere.) He estimated that work on Java EE seems to have stopped around November 2015.”

So, it’s clear there is industry concern that Oracle has backed off from involvement with development of JSRs for Java EE8. The question is, what happens now?

Posted on

Lightweight docker images for Java apps

There’s a number of posts (e.g. here) talking about the official Java docker images being on the large side – in Docker terms, the standard images at > 600MB before you even build your image containing you app are … pretty big.

Suggestions are to use a smaller image as a starting point, like Alpine Linux. It looks like at some point the official Java images have been updates to include a number of Alpine based images too.

Pulling down an OpenJDK 8 image, java:openjdk-8-jdk and then java:openjdk-8-alpine, there’s a massive size difference between the size of the two:

If you’re planning on running something lightweight like a Spring Boot app, looks like the provided Alpine images are a good starting point.

Proudly powered by WordPress