Interesting proposals: Java 9 and beyond

Spasi · May 27, 2016, 2:15pm

[quote=“princec,post:190,topic:55436”]
The current Panama prototype supports “machine code snippets”. You can write some code outside the JVM/JDK that makes the JVM inline and JIT-compile a method handle to one or more native CPU instructions (of your choice) that also play well with the JVM register allocator. This functionality alone could be used by a library to do amazing things.

API-wise, I wouldn’t expect anything pretty without syntactic sugar. But it is true that it is designed under the assumption that Java 10 will have value types and any-generics. This, in theory, will allow Java-ish code to perform just like native C.

princec · May 27, 2016, 7:28pm

All I can say is, it had better be as easy to use as C structs.

Cas

Spasi · May 27, 2016, 8:11pm

Some examples:

SnippetTest
Vector
UnixSystem

Btw, a Scope object is “a unit of resources allocation that can be released all together”. The current prototype has the NativeScope and HeapScope classes. The later uses long[] as the backing memory (on which you can map structs etc).

noctarius · May 27, 2016, 8:20pm

Yes correct, thanks for answering Was busy again the last days!

Icecore · May 28, 2016, 8:12am

Is everyone don’t care?
You can make List - by making custom List class with int[]
You can make operator overloads – by calling fun mul(a,b)
You can send fun as param


interface Fun<E>{
    public Do();
    public Do(E params);
}

You can even serialize and memory copy by Unsafe and direct buffer

But You can’t make struct(class) extend from 2 structs (classes)
Its fundamental JVM problem


class AA extends B,C,D{
}
class BB extends B,C,D{
}

fun(B data){
    do_B(data);
    if(data instanceof C){
        do_C(data);
    }
    if(data instanceof D){
        do_D(data);
    }
}
<T extends B & C & D> fun(T data){
    do_B(data);
    do_C(data);
    do_D(data);
}

up: i don’t think its good solution ^^


	class B_Data{}
	class C_Data{}
	class D_Data{}
	
	interface B{public B_Data get_B_Data();}
	interface C{public C_Data get_C_Data();}
	interface D{public D_Data get_D_Data();}
	class AA implements B, C, D{
		B_Data bd;
		public B_Data get_B_Data(){return bd;}
		C_Data cd;
		public C_Data get_C_Data(){return cd;}
		D_Data dd;
		public D_Data get_D_Data(){return dd;}
		
		public<T extends B & C & D> void Fun(T data){
			do_B(data);
			do_C(data);
			do_D(data);
		}
		public void do_B(B data){}
		public void do_C(C data){}
		public void do_D(D data){}
	}

What you think?)

VaTTeRGeR · May 28, 2016, 11:03am

Java 8 allows default implementations for interface methods, but (i think) interface fields are static final by default.


class AA extends B,C,D{
}
class BB extends B,C,D{
}

fun(B data){
    do_B(data);
    if(data instanceof C){
        do_C(data);
    }
    if(data instanceof D){
        do_D(data);
    }
}
<T extends B & C & D> fun(T data){
    do_B(data);
    do_C(data);
    do_D(data);
}

I don’t see a logical problem with this example.
You can also check if an interface is present on a class that might or might not have it, just like in your example where an instance of B might also have an implementation of C or/and D. Does it really make a difference whether the implementation is provided by implementing an interface or using multiple inheritance?


	class B_Data{}
	class C_Data{}
	class D_Data{}
	
	interface B{public B_Data get_B_Data();}
	interface C{public C_Data get_C_Data();}
	interface D{public D_Data get_D_Data();}
	class AA implements B, C, D{
		B_Data bd;
		public B_Data get_B_Data(){return bd;}
		C_Data cd;
		public C_Data get_C_Data(){return cd;}
		D_Data dd;
		public D_Data get_D_Data(){return dd;}
		
		public<T extends B & C & D> void Fun(T data){
			do_B(data);
			do_C(data);
			do_D(data);
		}
		public void do_B(B data){}
		public void do_C(C data){}
		public void do_D(D data){}
	}

What you think?)

I had to do something like this for adding versioning functionality to a class that was already extending a framework specific class, this is not the best example because it was only one addition to that class, but there sure is a use for multiple inheritance.

The interface version requires copy-pasting code around which is annoying, error-prone and time-consuming.
Most of these cases (and also my example) could be solved with simple inheritance, but deep class hierarchies kinda suck and are inflexible, it just doesn’t feel right to me to create a new class branch just to add a component to some class.

Icecore · May 28, 2016, 6:41pm

it Overridable


	   static interface ID{default public int get_I(){return 0;}}
	   static class A implements ID{}
	   static class B implements ID{@Override public int get_I(){return 1;}}
	   public static void main(String[] args){
		  pr(new A());//0
		  pr(new B());//1
	   }
	   static public void pr(ID id){System.out.println(id.getClass() + "=" + (id).get_I());}

I skip code spam varibles in extend clases ^^, its all about Data within…


//T data == class
data.Name = "T_Data";
//and Interfaces don't have local Data (variables)

Exactly – but when you have 2 big clases that already extends from something
you simple can’t merge them together by [icode]class extends A,B[/icode]

And creating clone object - bad solution
Because you cant send 2 same cloned classes in [icode]fun(class_1)[/icode] or [icode]List<class_1>[/icode]
Only if you implement them from same interface – but you don’t have direct access to data of that class
or you need copy-past all get’s/set’s – many useless copy past code…

p.s and Yes, I found out code solution only after I post the problem ^^ its looks weird but it works =)

VaTTeRGeR · May 28, 2016, 9:28pm

[quote]Exactly – but when you have 2 big clases that already extends from something
you simple can’t merge them together
[/quote]
I guess that’s why it isn’t included in Java, it could severely break things if used carelessly, diamond problem etc.

ags1 · May 28, 2016, 9:30pm

Multiple inheritance was a pre-existing feature of C++ that was explicitly excluded from Java from the very beginning because of the problems it can cause. Personally I see no need to add it to the language now.

princec · May 28, 2016, 9:58pm

If only there was some way to easily syntactically express composition…

Cas

Roquen · May 29, 2016, 7:42am

Multiple inheritance of state…always had multiple inheritance of type and the line is abit blurred with recent(ish) additions.

nsigma · May 29, 2016, 9:14am

Well, we’ve now got multiple inheritance of behaviour - doesn’t feel that blurred.

Icecore · May 29, 2016, 11:00am

I think its ok - after i found out this solution ^^ - So I think problem closed - with little overhead of code(And Mem)
All thanks


interface B{public B_Data get_B_Data();}
interface C{public C_Data get_C_Data();}

class B_Data implements B{public B_Data get_B_Data(){return this;}}
class C_Data implements C{public C_Data get_C_Data(){return this;}}

class BC_Data implements B, C{
  B_Data bd;
  public B_Data get_B_Data(){return bd;}
  C_Data cd;
  public C_Data get_C_Data(){return cd;}
}

Or even little crazy Sugar =)


class BC_Data_Ex implements B, C{
  B bd = new B_Data();
  public B_Data get_B_Data(){return bd.get_B_Data();}

  C cd = new BC_Data();
  public C_Data get_C_Data(){return cd.get_C_Data();}
}

basil · May 29, 2016, 12:34pm

[quote=“nsigma,post:212,topic:55436”]
sounds schizophrenic

Icecore · July 6, 2016, 9:03pm

Not good news rumors for Java:
Oracle About to Stop Supporting Java EE?

simple google question for more info…

Riven · July 6, 2016, 9:21pm

Keep in mind Java EE != Java JDK.

Obviously, Oracle will handle the fallout of all confusion in the worst possible way, and in 3 months time the story will be nuanced somewhat.

Icecore · July 6, 2016, 9:38pm

Yes, but who knows - what next?
(what point support them Java if they drop commercial Java EE, its Oracle - they leave not profitable projects )

Mac70 · July 7, 2016, 12:22am

I don’t think that Oracle would stop supporting Java platform - if it wouldn’t be profitable for them, they would most likely just sell it to someone else (and I am sure there would be at least few companies willing to buy it).

noctarius · July 7, 2016, 8:02pm

As part of the JCP EC I can assure, that the EC is aware of the problem as well and we approached Oracle for a statement. As an official and essential part of the Java ecosystem (in difference to the JavaEE Guardians) the JCP and JCP EC might have a better position to make Oracle to state their way, however I don’t think there will be any official comment in the next months.

If Oracle has proven to do one thing right it is to make decisions and to stick with them, no matter at what cost (look at OpenOffice for example).

Personally, and that is really my personal opinion, I couldn’t care less about JavaEE BUT I understand it is a big and important part of Java and essential for lots of companies (unfortunately ;-)).

ags1 · July 7, 2016, 8:45pm

I remember the big drive in the early 2000s in my former employer to hop on the EE train… which went nowhere. Plenty of frameworks out there, nobody needs EE, it’s just LegacEE.

As for regular Java, it has a freight train of momentum that enables it to survive any particular corporate backer. I might be naive, but what exactly does Oracle contribute that could not be replaced by a community process that would not doubt be liberally supported by a large number of enterprises?

@noctarius, going by your profile pic you are a spokesperson for XCOM?