Tag Archives: jdk

What Elon Musk can learn from Java App/Cloud Deployments!

I had an unproductive day yesterday!

I did nothing, but slept through most of the day. And then late night this next challenge of deploying the hush-hush java app over the cloud started to bother me.(afterall it was not a totally unproductive day, thinking wise!)

And then, flash back to a few days, where comparisons were made, what I am doing (javascript ehew!) and what one of the current top living inspiration in the current world Elon Musk is doing, and then I went into sad slumber!

Then yesterday happened, and then it clicked:: we Java devs(web ones, not hard core jdk ones) are orchestrating everything in lifecycle of what Elon Musk is trying to do!

Here is the analogy(it can be extended wonderfully!):

  1. The WAR(Web ARchieve)(sorry, I am old fashioned) is like the unmanned space ship.
  2. The dev JVM is like simulated Mars environment.
  3. The cloud is the SPACE where the bits travel to-and-fro in form of data/packets.
  4. The machine IP Address is like the lat/long of where you want to deploy.

So my current app is in its final integraton phase(hush-hush…) and I am trying to accomplish Slide Driven Development.(nice term!).

Slice Driven Development :: A development approach where a feature/flow is shipped to staging environment as soon as it becomes usable.

Currently I(with @explorer) are trying to integrate all features/flow of the hush-hush app, While I am totally unsure/unaware how it will behave when deployed on staging/production environment. Therefore, I had come up with this approach :: The momemt a feature becomes bug-discoverable, it ought be shipped so that:

  1. Move to the next flow..
  2. Bugs can be quashed..
  3. (most imp)Our path of going from dev–>staging–>production for any feature should be seamless and smooth like  skating on butter!

And then, a Eureka moment happened!! And this blog post came about!

Your Takeaway: If you are on a team working with Elon Musk(or anyone trying to transport stuff from place X to place Y, in an unsure environment), you can leverage from the experience of thousand if not millions of deployments of web java developers trying to deploy WAR file formats from local dev JVM to production JVM.

We know the nuances of this lifecycle!

It might save you some time! 🙂

Java Lookout — Java Language and Platform Futures @Devoxx, Belgium.

Feedback on watching the Java lookout!

1/Bad humour. Meh!

2/If you cannot commit anything to the language, why broadcast it? Are you scared of a features popularity? Rant on a similar thing in JavaEE

3/Spineless Humour!  https://youtu.be/oGll155-vuQ?t=564

4/Listen carefully :: “You may have to use type args more with lambda’s” https://youtu.be/oGll155-vuQ?t=721 So your principle of bringing least disruptive change FAILED!

5/Freeze the screen :: Which code is still less readable? https://youtu.be/oGll155-vuQ?t=830 Come on! Stop pushing #JEP286 #DieJEP286 IT DOES NOT MAKE SENSE. Simple!

6/Sadly the current Java architects are trying to add features to reduce developers time to build a feature. There are already players to do this: Spring et al. You should be focused to create the playground, and not the rules. Why can’t they understand this simple fact? Look at the earlier Java architects… Did they focus delivering a CS concept or ease of developer writing the code? Don’t outsmart Spring, Don’t outsmart IDE’s outsmart CS concepts and implement them in Java.

7/Improved Switch design is being talked about, this is a brainstorming topic, it does not make sense to show-off it *conceptually* here!

8/Value Types — Only needed if you are pixel developer or probably a compiler writer. A lot of people writing Java are Enterprise users. We have custom wrappers, and would *not* need Value Types. But nonetheless its a welcome feature!

9/Project Valhalla — Get a basic version out, build on it later. Do not try to deliver a 5 story building in one go. Deliver one layer per version.

10/The decision for priority of a feature should have been *complexity* and if some feature is wanted and do-able, IT SHOULD BE DONE AND NOT POSTPONED.

I have gone a lot rusty with Java! :-/

 

 

Javascript muggles don’t mess with Java’s strong type def structure!

Yes, this is going to be a rant post!

If you are in sync with the recent developments happening in/around open jdk you might have come across the JEP-286 | Local-Variable Type Inference

This JEP has been authored by none other than Brian Goetz and endorsed by Mark Reinhold himself(Yikes!).

I will straight away come to the points why I(no-one) vehematically (n:vehement) oppose this improvement!

  1. Code is read more than just written.
  2. There is max context when someone is writing an implementation for a method! All context needs to be dumped then and there. By bringing in this change, all this context will be lost for ever!
  3. This change introduces the idea of “I know its suppose to return X”, there will be no way to verify the claim, except the compiler-interpretation.
  4. Such changes belittle the language semantics! Well remember this: Milk of a lioness can be held in a gold container only else it goes sour! Java respects this semantics as of now! (Its really cool!).
  5. You can leverage power of automatic type suggestions while one is on RHS of the equation/statement, which has given a great boost to the language via lambdas. LHS *has* to be clearly defined.

Following are demo videos showing how easy and quickly one can do an alt-enter in your favorite ide and have the LHS of the assignment automagically inferred!

1/Simple example from the JEP

 

2/Complex examples using files from the same JEP

local_var_file

 

There are couple of surveys seeking public opinion on the same here are their links:

  1. Survey 1
  2. Survey 2

Finally, if you have seen Mark’s Java 9 intro speech, he starts off by talking about

1/No copy pasting a feature from any language just because its cool!

2/ Readability:

This JEP is not only killing Readability, but its not consistent across the language.!? There goes universality and compatibility into the garbage collector!

Let’s just keep evolving without giving up the things that make Java really stand strong on its feet! #DieJEP286

The Java Roadmap – Its second life.

Woo Hoo!

I am excited to know about Java being back on-track with its journey of being the most preferred in-demand platform.
I started following the development at the following interesting links:
Here’s what I have learnt in the last few hours:
1/With news about the next JDK releases slated for 2011 and late 2012, the java platform is in for a complete re-write much more intutive and more robust than ever before.
2/The sensor api is the answer to the recent advancements in the mobile domain viz-a-viz touch screen/GPS enabled life-apps. Looks like J2ME(or what ever it will be called) will reign in for the first time in serious cometetion!
3/Must read Project Coin.
4/Oracle’s official statement is adamant at keeping two versions alive for whatever product they already had and what they inherited from Sun. A tough situation to be in.
I have been recently loosing faith in what the future of java will be after Oracle took over and a lot of Sun luminaries quiting Oracle controlled java. Atleast I see new life(hard work and pain going in) in my most loved language, Ever!
I look forward to it with renewed hope!